This method puts the given node and all of its sub-tree into a
normalized form. A normalized sub-tree has no empty text nodes and no
adjacent text nodes.
Following the rules in the algorithm from
https://webidl.spec.whatwg.org/#js-platform-objects, "To Internally
create a new object implementing the interface interface", this change
incorporates the steps to load a prototype from new.target, and write
it to the created instance returned from constructor_impl(). This
mirrors the code for generate_html_constructor(), which incorporates
additional steps needed by Custom Elements.
Bug #334
Previously we would look for a matching ID, and then for a matching
name. If there was an element in the collection which had a matching ID
as well as an element with a matching name, we would always return the
element with a matching ID irrespective of what order that element was
in.
We can't rely on Element.setAttribute() in cloneNode() since that will
throw on weird attribute names. Instead, just follow the spec and copy
attributes into cloned elements verbatim.
This fixes a crash when loading the "issues" tab on GitHub repos.
They are actually sending us unintentionally broken markup, but we
should still support cloning it. :^)
This change adds the `captureEvents()` and `releaseEvents()` methods to
the window object. These methods are obsolete, but are still included
in the HTML specification, which says they must do nothing.
This change adds the `clear()`, `captureEvents()` and `releaseEvents()`
methods to the document object. These methods are obsolete, but are
still included in the HTML specification, which says they must do
nothing.
Our implementation was errantly matching HTML tags other than the list
specified by the spec. For example, a <meta name=title> tag would be a
match for document.title.
For example, bandcamp will dynamically update its title when audio is
played as follows:
document.title = "▶︎ " + document.title;
And bandcamp also has a <meta name=title> tag. The result was that the
title would become "▶︎ [object HTMLMetaElement]".
When inserting a node into a parent, any live DOM ranges that reference
the parent may need to be updated. The spec does this by increasing or
decreasing the start/end offsets of each live range *before* actually
performing the insertion.
This caused us to crash with a verification failure, since it was
possible to set the range offset to an invalid value (that would go on
to immediately become valid after the insertion was finished).
This patch fixes the issue by adding special badged helpers on Range for
Node to reach into it and increase/decrease the offsets during node
insertion. This skips the offset validity check and actually makes our
code read slightly more like the spec.
Found by Domato :^)
The loop that was supposed to check the chain of previous or next
siblings had a logic mistake where it would never traverse the chain,
so we would get stuck looking at the immediate sibling forever.
By moving scroll offset clamp from `PaintableBox::scroll_by()` to
`PaintableBox::set_scroll_offset()`, we ensure that updates from
`Element::set_scroll_top()` and `Element::set_scroll_left()` are
constrained to a valid range.
We now cache potentially named elements on the Document when elements
are inserted and removed. This allows us to do lookup of what names are
supported much faster than if we had to iterate the tree every time.
This first cut doesn't implement the rules for 'exposed' object and
embed elements.
Elements are now collected according to paint order as spec says,
replacing the depth-first traversal of the paint tree with hit-testing
on each box.
This change resolves a FIXME in an existing test and adds a new
previously non-working test.
This change modifies hit_test() to no longer return the first paintable
encountered at a specified position. Instead, this function accepts a
callback that is invoked for each paintable located at a position, in
hit-testing order.
This modification will allow us to reuse this call for
`Document.elementsFromPoint()` in upcoming changes.
This API seems to be used by WPT for sending synthetic input events.
Implementing the naive translation of elementFromPoint to the spec steps
for this algorithm turns 4 'tests had errors unexpectedly' and 3 'tests
had timeouts unexpectedly' into 1 pass and 7 'tests had unexpected
subtest results' on the infrastructure/ subdirectory of WPT.
Similar to another problem we had in CharacterData, we were assuming
that the offsets were raw utf8 byte offsets into the data, instead of
utf16 code units. Fix this by using the substring helpers in
CharacterData to get the text data from the Range.
There are more instances of this issue around the place that we will
need to track down and add tests for, but this fixes one of them :^)
For the test included in this commit, we were previously returning:
llo💨😮
Instead of the expected:
llo💨😮 Wo
We were previously assuming that the input offsets and lengths were all
in raw byte offsets into a UTF-8 string. While internally our String
representation may be in UTF-8 from the external world it is seen as
UTF-16, with code unit offsets passed through, and used as the returned
length.
Beforehand, the included test included in this commit would crash
ladybird (and otherwise return wrong values).
The implementation here is very inefficient, I am sure there is a
much smarter way to write it so that we would not need a conversion
from UTF-8 to a UTF-16 string (and then back again).
Fixes: #20971
This is a pretty straightforward test, but I managed to make this crash
on real sites while trying to fix#20971 without any other test in the
existing suite failing.
