CORS cross-origin responses in the No CORS request mode provide an
opaque filtered response, which is the original response with certain
attributes removed/changed.
The relevant effect it has is setting the body to `null`, which means
`body_bytes` has `Empty` in the process_response_consume_body callback.
This effectively disables cross-origin linked resources
(e.g. stylesheets).
However, the web actually depends on this, especially for stylesheets
retrieved from a cross-origin CDN. For example, Shopify websites
request stylesheets from `cdn.shopify.com` and Substack websites
request stylesheets from `substackcdn.com`.
This makes this a specification bug, as this code was written from it.
The workaround is to read the actual body from the unfiltered response
and then call `process_linked_resource` from there.
This _should_ be safe to do, as linked resource fetches do not include
credentials (i.e. cookies and the Authorization header), so it cannot
provide personalized responses.
This would previously assert in InlineFormattingContext because we had
an outwardly inline box that wasn't inwardly flow.
Fix this by converting text-based input boxes to inline-blocks. This is
an ad-hoc solution, and there might be a much better way to solve it.
Previously, empty text boxes would fall back to the min-height: 16px
set on the <input> element. As soon as there is any content they
would usually gain height because the line height of that text is
more than 16px (depending on the font/font-size used).
Now they use height: 1lh for the inner div (which contains the
actual text), which matches the exact height of 1 line of content.
These are currently initialized in a [[gnu::constructor]], which has a
weird initialization order. These constructors are invoked before main()
and, incidentally, before any user-defined default constructors of the
static strings they are initializing.
This will become an issue when these strings are ported to FlyString,
which has a user-defined default constructor. In that scenario, when the
FlyString constructor is executed after the [[gnu::constructor]], the
strings will be "reset" to the empty string.
Instead of relying on a non-standard compiler extension here, let's just
initialize these strings explicitly during main-thread VM creation, as
this now happens in WebContent's main().
Checkedness of an input element can influence sibling style, as well as
style of their children, when they use the `:checked` pseudo-class in
combination with a kind of sibling selector. That means its not
sufficient to just invalidate the input elements on style.
This is actually more commonly observable than one might expect, because
this pattern is often used as a JS-free toggle solution for things like
menus.
Previously HTMLProgressElement implemented is_html_input_element() not
is_html_progress_element(), so is_html_progress_element() defaulted to
always returning false. This broke is<HTML::HTMLProgressElement>().
With current process architecture where every top level browsing
context lives in a separate WebContent process we need to request
a browser to spawn new WebContent process if new top level BC is
requested.
Introducing class for abstract browsing context is going to make it
possible to have separate implementations for:
1) Local browsing context (Top level BC of current page and iframes)
2) Remote browsing context (BC of a page that lives in another
WebContent process)
For example, consider the attribute:
interface Element {
[PutForwards=value] readonly attribute DOMTokenList classList;
}
When `classList` is set, we should instead set the attribute `value` on
the `classList` attribute of the Element interface.
This is where it belongs according to the spec, and where these methods'
IDL will be placed.
This forces us to implement a few steps closer to the spec as well.
LibGUI and WebDriver (read: JSON) API boundaries use DeprecatedString,
so that is as far as these changes can reach.
The one change which isn't just a DeprecatedString to String replacement
is handling the "null" prompt response. We previously checked for the
null DeprecatedString, whereas we now represent this as an empty
Optional<String>.
The UTF-8 encoding of U+00A0 (NBSP) is the bytes 0xc2 0xa0. By looping
over the string to escape byte-by-byte, we replace the second byte with
" ", but leave the first byte in the resulting text. This creates
an invalid UTF-8 string, with a lone leading byte.
