Otherwise finalization step of initial `about:blank` navigation might
cancel user-initiated navigations by changing ongoing navigation id.
This is implemented by marking navigable as ready to start processing
navigation in SHTQ task, because we know for sure this task cannot be
processed until finalization step of initial `about:blank` navigation
is done.
Previously, we would only keep the cell that must survive alive, but
none of it's edges.
This cropped up with a GC UAF in must_survive_garbage_collection of
WebSocket in .NET's SignalR frontend implementation, where an
out-of-scope WebSocket had it's underlying EventTarget properties
garbage collected, and must_survive_garbage_collection read from the
destroyed EventTarget properties.
See: https://github.com/dotnet/aspnetcore/blob/main/src/SignalR/clients/ts/signalr/src/WebSocketTransport.ts#L81
Found on https://www.formula1.com/ during a live session.
Co-Authored-By: Tim Flynn <trflynn89@pm.me>
This change fixes a bug that can be reproduced with the following steps:
```js
const iframe = document.createElement("iframe");
document.body.appendChild(iframe);
iframe.contentWindow.location.href = ("http://localhost:8080/demo.html");
```
These steps are executed in the following order:
1. Create iframe and schedule session history traversal task that adds
session history entry for the iframe.
2. Generate navigation id for scheduled navigation to
`http://localhost:8080/demo.html`.
3. Execute the scheduled session history traversal task, which adds
session history entry for the iframe.
4. Ooops, navigation to `http://localhost:8080/demo.html` is aborted
because addings SHE for the iframe resets the navigation id.
This change fixes this by delaying all navigations until SHE for a
navigable is created.
We hold a raw pointer to the mouse selection target, which is a mixin-
style class inherited only by JS::Cell classes. By not visiting this
object, we sometime had a dangling reference to it after it had been
garbage collected.
This change — part of the HTML constraint-validation API (aka
“client-side form validation”) — implements the willValidate IDL/DOM
attribute/property for all form controls that support it.
Previously, the charset of name "UTF-16BE/LE" would be checked against
when following standards to convert the charset to UTF-8, but in
reality, the charsets "UTF-16BE" and "UTF-16LE" should be checked
separately.
Co-authored-by: Jelle Raaijmakers <jelle@ladybird.org>
Corresponds to part of https://github.com/whatwg/html/pull/9841 and then
https://github.com/whatwg/html/pull/11047
Adding `Auto` as a type state feels a little odd, as it's not an actual
type allowed in HTML. However, it's the default state when the value is
missing or invalid, which works out the same, as long as we never
serialize "auto", which we don't.
Regressed in 036327332f.
This commit moves the optimization a little later in replaceData(),
still avoiding relayout (the important part).
Recovers 480 points on WPT. :^)
We were incorrectly treating cellpadding=0 as if the attribute was
missing. This commit fixes it so it behaves as `padding: 0` on cells.
When adding a test, I discovered that we were not invalidating style for
cells when their containing table's cellpadding attribute changed.
So this commit fixes that as well.
Since we don't support the "variant" meta tag stuff in WPT, I've simply
copied the test files here, and then test.js looks at the filename to
figure out which test function to use.
This incrases our coverage of the HTML parser substantially by also
invoking it via document.write() one-shot, and character-at-a-time.
When constructing an entry list, XHR::FormDataEntry is created
manually and appended to the entry list instead of using the
spec-defined method of creating an entry.
If the expansion of a custom property in variable expansion returns
tokens, then the custom property is not the initial guaranteed-invalid
value.
If it didn't return any tokens, then it is the initial
guaranteed-invalid value, and thus we should move on to the fallback
value.
Makes Shopify checkout show the background colours, borders, skeletons,
etc.
This is a weird behaviour specific to `font` - it can reset some
properties that it never actually sets. As such, it didn't seem worth
adding this concept to the code generator, but just manually stuffing
the ShorthandStyleValue with them during parsing.
