Just creating a stream on the JS heap isn't enough, as we will later
crash when trying to read from that stream as it hasn't been properly
initialized. Instead, until we have teeing implemented (which is a
rather huge part of the Streams spec), create streams using proper AOs
that do initialize the stream.
For some reason on macOS with ASAN enabled, the test promises in
HTML/Window-postMessage do not resolve. These promises wait for both
the in-document and the blob url iframes to load. It's not clear why
this works fine in Linux nor why the onload handler doesn't fire
when the iframe has already loaded.
This attribute has some compatbility issues...
- The spec says it should be an SVGAnimatedRect which contains
a DOMRect and a DOMReadOnlyRect.
- Blink gives you an SVGAnimatedRect with 2x SVGRect
- Gecko gives you an SVGAnimatedRect with 2x SVGRect? (nullable)
I ended up with something similar to Gecko, an SVGAnimatedRect
with 2x DOMRect? (nullable)
With this fixed, we can now load https://polar.sh/ :^)
Window and other global objects are not technically legacy platform
objects, and have other ways to override their setters and getters.
However, Window does need to share some code with the legacy platform
object paths, and simply adding another bool check to the mix seems
the shortest putt.
HTML fragments are parsed with a temporary HTML document that never has
its flag set to say that it is ready to have scripts executed. For these
fragments, in the HTMLParser, these scripts are prepared, but
execute_script is never called on them.
This results in the HTMLParser waiting forever on the document to be
ready to have scripts executed.
To fix this, only wait for the document to be ready if we are definitely
going to execute a script.
This fixes a hang processing the HTML in the attached test, as seen on:
https://github.com/SerenityOS/serenityFixes: #22735
When the caller of NumericCalculationNode::resolve() does not provide
a percentage_basis, it expects the method to return a raw percentage
value.
Fixes crashing on https://discord.com/login
With this change, a stacking context can be established by any
paintable, including inline paintables. The stacking context traversal
is updated to remove the assumption that the stacking context root is
paintable box.
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
The JS::Value being passed through is not a bigint, and needs to be
converted using ConvertToInt, as per:
https://webidl.spec.whatwg.org/#es-unsigned-long-long
Furthermore, the IDL definition also specifies that this is associated
with the [EnforceRange] extended attribute.
This makes it actually possible to pass through an autoAllocateChunkSize
to the ReadableStream constructor without it throwing a TypeError.
This aligns Workers and Window and MessagePorts to all use the same
mechanism for transferring serialized messages across realms.
It also allows transferring more message ports into a worker.
Re-enable the Worker-echo test, as none of the MessagePort tests have
themselves been flaky, and those are now using the same underlying
implementation.
We would previously not return a RadioNodeList in the curious case where
a named item resolves to two different elements within the form.
This was not a problem when calling namedItem directly in the IDL as
named_item_or_radio_node_list shadows named_item but is exposed when
calling the property through array bracket notation (as an example).
Fix this, and add a bunch more tests to cover
HTMLFormControlsCollection.
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
Calling test() multiple times in the same test file is not actually
valid, and can cause the following test to hang forever. So let's stop
doing that in the one test that did so, and also prevent the same
mistake happening again. :^)
Throwing an exception on subsequent test() calls means that we don't
hang, the test will fail with missing output, and we get a log message
explaining why.
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.
This is to allow future changes to do cross-process MessagePorts in an
implementation-agnostic way. Add some tests for this behavior.
Delivering messages that were posted to a MessagePort just before it was
transferred is not yet implemented still.
Fixes following mistakes:
- "scrolling box" for a document is not `scrollable_overflow_rect()`
but size of viewport (initial containing block, like spec says).
- comparing edges of "scrolling box" with edges of target element
does not make any sense because "scrolling box" edges are relative
to page while result of `get_bounding_client_rect()` is relative
to viewport.
