This implements parsing part of customizable <select> spec update.
See whatwg/html PR #10548.
Two failing subtests in `html5lib_innerHTML_tests_innerHTML_1.html`
and `customizable-select/select-parsing.html` are due to the spec
still disallowing `<input>` inside `<select>`, even though Chrome
has already implemented this behavoir (see whatwg/html#11288).
Having the dumping code in a separate Dump.cpp meant that it was often
overlooked when the rules gained new features, and also limits dumping
to publicly-accessible information.
I missed when these changes actually happened, but the big differences
here are that a few steps got extracted into their own algorithms; and
the dialog now only does things when it's attached to a fully-active
document, instead of immediately.
I've imported a WPT test that exercises this by calling show() on an
unattached dialog.
We previously had this implemented in an ad-hoc way, where we used a
boolean on the CloseWatcher instead of a proper function with steps.
This worked at the time, but causes problems with the current version
of the spec, so let's just implement it properly.
This commit consciously does not update the spec text, because it's
diverted quite a lot. That will happen in a subsequent commit.
To update to ICU 78.1, a bump to the Vcpkg baseline is required.
However, for some reason 1.3.0#0 fails to compile on the newer
baseline. Updating to 1.3.0#1 fixes the issue.
The m_last_match, m_left_context, and m_right_context views were being
created from a temporary string instead of from the owned m_input.
This caused the views to point to destroyed stack memory when accessing
RegExp.lastMatch after calling String.replace() with a regex.
From the spec:
> The owning element of a transition refers to the element or
pseudo-element to which the transition-property property was applied
that generated the animation.
https://drafts.csswg.org/css-transitions-2/#owning-element
Previously we only stored the element.
This patch adds an API for posting a Core::Event::Type to the thread
event queue without requiring a full Core::Event object.
We use this API to avoid heap allocations for every timer and notifier
activation event.
If a script on the page cancels a mousemove event, we would return early
and neglect to update the cursor. This is seen regularly on "Diablo Web"
where they set the cursor to "none" on the main canvas, and also cancel
mousemove events.
Our existing implementation was checking if the generator step result
was `undefined` to indicate that the generator is complete. This is
not sufficient for an upcoming implementation of Iterator.concat, where
`undefined` is used as an incomplete iteration result.
Instead, let's have the Iterator prototype return an IterationResult to
explicitly indicate its completeness. As a result, the prototype also
looks more like the spec now.
The DeferredInvocationContext only existed to satisfy the requirement
in ThreadEventQueue that each event has an EventReceiver. However,
deferred_invoke() was not even using the EventReceiver to call its
callback. Therefore, we don't need to allocate one for every deferred
invocation.
This also prevents WeakPtr::strong_ref() from racing and leaking the
context object when invoking a function across threads.
For some reason, it seems that passing NonnullRefPtr<SeekData> const&
was causing us to triple ref() in the capture group for the audio seek
handlers, followed by only a single unref(). Changing this to plain old
SeekData& inexplicably fixes the leak.
