Element styles should be invalidated when they depend on CSS variables
defined in one of their ancesors or when one of their ancestors change
their class, due to the possibility of adding new CSS variables in
scope.
We now parse `<counter-name>` values as a `<custom-ident>`. This
disallows `default` and CSS-wide keywords as counter names. The
specification additionally disallows `none` as a counter name.
Before this change, the layout tree for slots was only updated after
creating a layout node for the slot itself. This was not enough to
account for partial layout tree rebuilds when the slot content changed.
With this change, we always recurse into the slot content.
Fixes expanding and collapsing of nodes in DOM tree inspector broken in
9b26f7eb0f
The public one at echo.websocket.org tends to be slow at times,
frequently causing timeouts. Ideally we would run a local websocket
server but for now we can make do with a self-hosted alternative.
When setting scroll position during page load we need to consider
whether we actually have a fragment to scroll to. A script may already
have run at that point and may already have set a scroll position.
If there is an actual fragment to scroll to, it is fine to scroll to
that fragment, since it should take precedence. If we don't have a
fragment however, we should not unnecessarily overwrite the scroll
position set by the script back to (0, 0).
Since this problem is caused by a spec bug, I have tested the behavior
in the three major browsers engines. Unfortunately they do not agree
fully with each other. If there is no fragment at all (e.g. `foo.html`),
all browsers will respect the scroll position set by the script. If
there is a fragment (e.g. `foo.html#bar`), all browsers will set the
scroll position to the fragment element and ignore the one set by
script. However, when the fragment is empty (e.g. `foo.html#`), then
Blink and WebKit will set scroll position to the fragment, while Gecko
will set scroll position from script. Since all of this is ad-hoc
behavior anyway, I simply implemented the Blink/WebKit behavior because
of the majority vote for now.
This fixes a regression introduced in 51102254b5.
Because we cache the transformed text string in text nodes affected by
text-transform, we have to actually update the layout tree when this
property value changes.
This change fixes a bug in our implementation of the “step base”
algorithm at https://html.spec.whatwg.org/#concept-input-min-zero. We
were using the “value” IDL/DOM attribute in a particular step, where the
spec instead actually requires using the “value” content attribute.
A font-size with rem units need to resolve against the default font
metrics for the root element, otherwise every time we compute style,
the reference value for rem units grows.
This fixes an issue where text on some web pages would grow every time
there was a relayout. This was very noticeable on https://proton.me/Fixes#339
We already have logic to play or cancel animations in an element's
subtree when the display property changes to or from none. However,
this was not sufficient to cover the case when an element starts/stops
being nested in display none after insertion.
We set the page's focused navigable upon mouse-down events from the UI.
However, we neglected to ever clear that focused navigable upon events
such as subsequent page navigations. This left the page with a stale
reference to a no-longer-active navigable. The effect was that any key
events from the UI would not be sent to the new page until either the
reference was collected by GC, or another mouse-down event occurred.
In the test added here, without this fix, the text sent to the input
element would not be received, and the change event would not fire.
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>
