Instead of collecting all documents in a big vector and then filtering
the vector (twice!) with remove_all_matching(), we now pass a filter
callback to documents_in_this_event_loop_matching() and avoid all the
extra shuffling work.
Saw this stuff hogging ~20% of CPU time when profiling a WebContent
process in the middle of a WPT run.
In particular, input character lookahead now knows how to stop at the
insertion point marker if needed.
This makes it possible to do amazing things like having document.write()
insert doctypes one character at a time.
This is necessary to avoid a circular reference when including
Serializable.h in DOMException.h.
This moves the definition of SerializationRecord, SerializationMemory,
and DeserializationMemory into LibWeb/Forward.h so that Serializable.h
only needs to include LibWeb/Forward.h.
If we reach the insertion point at the same time as we switch to another
tokenizer state, we have to bail immediately without proceeding with the
next code point. Otherwise we'd fetch the next token, get an EOF marker,
and then proceed as if we're at the end of the input stream, even though
more data may be coming (with more calls to document.write()..)
The repository being in static storage is a bit of a hodgepodge, but in
line with how our current storage partitioning is done. We should
eventually move this, along with other across browsing context APIs to a
proper location at a later stage. But for now, this makes progress on
the meat of the BroadcastChannel API.
This one is particularly weird as there's a priority order, and we even
have to look at attributes from the container element if we're inside a
subframe.
This is an ad-hoc hack papering over the fact that we can apparently
end up in these places without an active window, and proceeding without
one leads to assertions on WPT.
Also removing a FIXME about not covering all of the event names as it is
not exactly clear when such a FIXME would be addressed, especially as
these come from multiple specifications.
Previously, the list was copied when constructing the FormData object,
then the original list was passed to the event, meaning any changes to
the list that happened within the event would not be reflected outside
of it.
In line with the ShadowRealm proposal changes in the WebIDL spec:
webidl#1437 and supporting changes in HTML spec.
This is required for ShadowRealms as they have no relevant settings
object on the shadow realm, so fixes a crash in the QueueingStrategy
test in this commit.
These interfaces are exposed on *, meaning it should work for workers
and our newly added shadow realm global object by being stored on the
universal global scope mixin.
I believe this is an error in the UI Events spec, and it should be
updated to match the HTML spec (which uses WindowProxy everywhere).
This fixes a bunch of issues already covered by existing WPT tests.
Spec bug: https://github.com/w3c/uievents/issues/388
Note that WebKit has been using WindowProxy instead of Window in
UI Events IDL since 2018:
816158b4aa
In #1537, determine_the_origin() changed to take
`Optional<URL::URL> const&` as first parameter, but it's passed
`Web::Fetch::Infrastructure::Response::url()`, which returns
`Optional<URL::URL const&>`. Ladybird does not have
SerenityOS/serenity#22870 (yet?), so this mismatch silently creates
a copy.
Change determine_the_origin() to take `Optional<URL::URL const&>`
instead. No behavior change, saves a copy, and is probably what
was originally intended.
The WebSocket spec tells us to queue tasks instead of firing events
synchronously at WebSockets, so this commit does exactly that.
The way we've implemented web sockets means that the work is spread
across multiple libraries and even processes, which is why it doesn't
look like the spec verbatim.
The MessagePort one in particular is required by Cloudflare Turnstile,
as the method it takes to run JS in a worker is to `eval` the contents
of `MessageEvent.data`. However, it will only do this if
`MessageEvent.isTrusted` is true, `MessageEvent.origin` is the empty
string and `MessageEvent.source` is `null`.
The Window version is a quick fix whilst in the vicinity, as its
MessageEvent should also be trusted.
Resulting in a massive rename across almost everywhere! Alongside the
namespace change, we now have the following names:
* JS::NonnullGCPtr -> GC::Ref
* JS::GCPtr -> GC::Ptr
* JS::HeapFunction -> GC::Function
* JS::CellImpl -> GC::Cell
* JS::Handle -> GC::Root
This shouldn't just be a simple reflection of the label attribute.
It also needs fallback to the HTMLOptionElement.text property if the
label attribute is absent.
Fix the function signatures of Canvas.toDataURL() and Canvas.toBlob()
and make both functions accept non-numbers as the quality parameter, in
which case it will just use the default quality instead of raising an
exception.
This makes toDataURL.arguments.1.html, toDataURL.arguments.2.html and
toDataURL.jpeg.quality.notnumber.html in
wpt/html/semantics/embedded-content/the-canvas-element pass :^)
We currently have 2 virtual methods to inform DOM::Element subclasses
when an attribute has changed, one of which is spec-compliant. This
patch removes the non-compliant variant.
Instead, smuggle it in as a `void*` private data and let Javascript
aware code cast out that pointer to a VM&.
In order to make this split, rename JS::Cell to JS::CellImpl. Once we
have a LibGC, this will become GC::Cell. CellImpl then has no specific
knowledge of the VM& and Realm&. That knowledge is instead put into
JS::Cell, which inherits from CellImpl. JS::Cell is responsible for
JavaScript's realm initialization, as well as converting of the void*
private data to what it knows should be the VM&.
Now that the heap has no knowledge about a JavaScript realm and is
purely for managing the memory of the heap, it does not make sense
to name this function to say that it is a non-realm variant.
The main motivation behind this is to remove JS specifics of the Realm
from the implementation of the Heap.
As a side effect of this change, this is a bit nicer to read than the
previous approach, and in my opinion, also makes it a little more clear
that this method is specific to a JavaScript Realm.