We are currently returning LibJS's invalid code point message, but not
formatting it with the bad value. So we get something like:
Unhandled JavaScript exception: [TypeError] Invalid code point {},
must be an integer no less than 0 and no greater than 0x10FFFF
So not only is the error unformatted, but it's inaccurate; in this case,
the byte cannot be larger than 255.
The WebIDL for the `Headers` constructor specifies that the `init`
parameter is optional and must be of type `HeadersInit`. While the
parameter can be omitted (or explicitly set to `undefined`),
`null` is not a valid value.
This change fixes at least 2 "Create headers with null should throw"
WPT subtests which I have imported in this patch.
It is the responsibility of code that deals with TypedArrays to apply
the byte offset and byte length. Not doing this caused Unity Web to
crash, as they call getRandomValues with views into their full main
memory. Previously, it would fill their entire memory of about 33.5 MB
with random bytes.
This triggers a mouse button press without the up event, allowing us to
e.g. simulate a selection by moving the mouse while keeping the button
depressed.
The DOM spec defines what it means for an element to be an "editing
host", and the Editing spec does the same for the "editable" concept.
Replace our `Node::is_editable()` implementation with these
spec-compliant algorithms.
An editing host is an element that has the properties to make its
contents effectively editable. Editable elements are descendants of an
editing host. Concepts like the inheritable contenteditable attribute
are propagated through the editable algorithm.
Instead of recursively iterating all descendants of the common ancestor
of the new line range that are not contained by that range, skip the
entire node tree as soon as we determine they're not.
Before, on a mouse-move event, if the hovered html element did not have
a tooltip or it was not a link, `page_did_leave_tooltip_area()` and
`page_did_unhover_link()` virtual functions would get called.
Now, the page remembers if it is in a tooltip area or hovering a link
and only informs of leaving or unhovering only if it was.
Before, on *every* mouse-move event, `page_did_request_cursor_change()`
virtual function would get called, requesting to change cursor to the
event's mouse position's cursor.
Now, the page keeps track of the last cursor change that was requested
("page's current cursor") and only requests cursor change again if and
only if the current cursor is not already the one that is required.
Whenever we create a GC function, it should always be so that we can
pass it to a platform event loop spin, HTML event loop spin, or some
queued task on the HTML event loop. For every use case, any local
variables will be out of scope by the time the function executes.
Using a default reference capture for these kinds of tasks is dangerous
and prone to error. Some of the variables should for sure be captured
by value so that we can keep a GC object alive rather than trying to
refer to stack objects.
These variables are all captured in queued events or other event loop
tasks, but are all guarded by event loop spins later in the function.
The IGNORE_USE_IN_ESCAPING_LAMBDA will soon be required for all locals
that are captured by ref in GC::Function as well as AK::Function.
By actually using streams, they get marked as disturbed and the
`.bodyUsed` API starts to work. Fixes at least 94 subtests in the WPT
`fetch/api/request` test suite.
Co-authored-by: Timothy Flynn <trflynn89@pm.me>
The spec for filtered responses states:
Unless stated otherwise a filtered response’s associated concepts
(such as its body) refer to the associated concepts of its internal
response.
This includes setting its associated concepts. In particular, when the
filtered response's body is set upon fetching a request with integrity
metadata, we must set the internal response's body instead.
Further restrictions that apply to filtered response subclasses (such as
opaque filtered responses having a status code of 0) are already
implemented.
In particular, the processBody callback here *can't* move the
processBodyError callback. It is needed a few lines after. Passing by
value is safe and intended here.
Done by forward declaring the required functions and defining the needed
constants. The defines shouldn't collide as they are from memoryapi.h.
This is done to avoid including windows.h.
