With the introduction of shadow realms, there will be two different
possible host defined objects. For clarity, rename the existing host
defined object to PrincipalHostDefined.
We were neglecting to check the namespace when looking for a specific
type of element on the stack of open elements in many cases.
This caused us to confuse HTML and SVG elements.
Element::tag_name() returns an uppercased string for HTML elements,
which is usually not what's expected by the parser algorithms that look
at tag names.
Letter spacing is applied during text shaping and `shape_text` is used
in places other `InlineLevelIterator` so way may have more work to do,
however this is a good start :^).
This fixes 3/4 of the remaining test failures in wpt/png/apng. Also,
about half of the APNG files on
https://commons.wikimedia.org/wiki/Category:Animated_PNG_files
used to be broken, and they all seem to work properly now :^)
I also refactored the code to be (at least to me) simpler and more
similar to what the spec describes. As a nice side effect, there are now
fewer lines of code than before.
Lastly, I replaced DeprecatedPainter with Painter.
The current shadow realm constructor implementation was based off a
merge request to the shadow realm proposal for integration into the
web platform. However, this merge request had a bug which we had
applied a workaround for by popping off the execution stack.
Since then, the spec has had an update of:
https://github.com/tc39/proposal-shadowrealm/commit/28b0cc
Which closer aligned the mainline spec to the proposed merge request.
Now, the original shadow realm proposal merge request has been closed
and a new one has been reopened with a much more minimal set of changes
that merely adds extra arguments to HostInitializeShadowRealm, which
this commit aligns with.
Noone needs to use this any more :^)
This is somewhat AD-HOC in the constructor as it is based on an open
shadow realm merge request, but applies the intent of the change without
any change in behaviour.
The use of extract_parameter_arguments_and_body() here is to make things
a little less awkward. If we were to exactly follow spec there would be
an awkward handling of the case that no arguments were provided and we
needed to provide an empty string.
To do this, we would need to either:
- Provide an Optional<Value> for bodyString to CreateDynamicFunction
- Create a new empty PrimitiveString wrapped in a JS Value.
Either case is somewhat awkward. Instead, just refactor this logic
outside of CreateDynamicFunction and make the caller do it.
Otherwise, this commit prepares for the new definition of
HostEnsureCanCompileStrings.
All callers have been made async, i.e. they now all provide a completion
callback. Let's make the callback required to discourage any future sync
usage.
If the attribute value is the empty string `(lang="")`, the language
is set to unknown. `lang` attribute higher up in the document tree
will no longer be applied to the content of that element.
This updates the CSS parser to support the keyword 'none' in the CSS4
color functions. The underlying CSSColorValue already supports this
keyword, meaning the parser can instantiate the color directly.
We track this node ID to navigate to a default element when opening the
Inspector. So for all intents and purposes, <frameset> and <body> should
be treated the same.
We guarded one step against a null navigable, but the very next step
also needs to be protected. Let's just abort early instead. This was
caught by the following imported WPT test:
html/dom/elements/the-innertext-and-outertext-properties/innertext-setter.html
This test adds a <frame> element and immediately removes it, but the
task to process the src attribute is already queued. Note that <iframe>
would have the same issue, but this test does not include them.
NavigableContainer is our home grown concept which already contains the
AOs needed for frame and iframe elements. This patch simply aligns our
HTMLFrameElement implementation with this class.
A couple of notes:
1. The <script> in the <head> element is intentional. The <frameset>
element effectively takes the place of the <body> element, and we
cannot add a <script> to a <frameset> element.
2. We don't render <frameset> or <frame> at all. Rendering is defined
in the following spec:
https://html.spec.whatwg.org/multipage/rendering.html#frames-and-framesets
3. If you load the test page in your browser, you won't see anything,
regardless of (2). Our test infra adds a <pre> element to the "body"
element (which is the <frameset> element here). Such children will
never be rendered. In the future, we could come up with something
better for our test infra to do, but this isn't important anyways
for this test - we can still grab the <pre> element's innerText.
