Without this, a worker can be GC'd in a very simple script such as:
const worker = new Worker("script.js");
worker.onmessage = () => {};
Where script.js attempts to post a message back to the parent window.
When the Worker is GC'd, the IPC connection from the WebContent process
to the WebWorker process is closed. When this occurs, the WebWorker will
exit() from LibIPC, and any message from the worker to its parent does
not have a chance to run.
CSS fragmentation implies 1:N relationship between layout nodes and
paintables. This change is a preparation for implementation of inline
fragmentation where InlinePaintable will be replaced with
PaintableWithLines corresponding to each line.
These don't have to worry about the input not being valid UTF-8 and
so can be infallible (and can even return self if no changes needed.)
We use this instead of Infra::to_ascii_{upper,lower}_case in LibWeb.
This is an ad-hoc change to account for the fact that we may run
arbitrary code while waiting for the tasks in this function to complete.
I don't have a way to reproduce it, but I've seen trouble caused by
navigables disappearing, which causes the history step numbers to be
disturbed.
This was previously negated due to a misread of
https://url.spec.whatwg.org/#concept-url-equals. This change fixes a
bunch of WPT crashes such as
"/html/browsers/history/the-history-interface/001".
There was no need to use FlyString for error messages, and it just
caused a bunch of churn since these strings typically only existed
during the lifetime of the error.
This is a method defined in the WebDriver spec, but requires access to a
bunch of private fields in these classes, so this is implemented in the
same manner as the reset algorithm.
Before this change, we transferred the input element's line-height to
both the editable text *and* the placeholder. This caused some strange
doubling of the effective line-height when the editable text was empty,
pushing down the placeholder.
The spec expects `postMessage()` to act as if it is invoked
immediately. Since `postMessage()` isn't actually invoked immediately,
keep tasks with source `PostedMessage` in the task queue, so that these
tasks are processed. Fixes a hang when `WorkerGlobalScope.close()` is
called immediately after `postMessage()`.
Partially reverting a3149c1ce9
Spinning the event loop was causing a crash on:
https://wpt.live/url/percent-encoding.window.html
As it was turning what is meant to be a synchronous operation into an
asynchronous one.
The sequence demonstrated by the reproducing test is as follows:
* A src attribute is changed for the iframe
* process_the_iframe_attributes entered with valid content navigable
* Event loop is spun, allowing the queued iframe removal to execute
* process_the_iframe_attributes continues with null content navigable
* 💥
Which fixes the following WPT test from failing due to issues stemming
from all of the windows which have been opened.
https://wpt.live/url/failure.html
This will give us 1205 new subtests passing in WPT.
If, by the time we need to schedule rendering of the next frame, the
previous one is still not processed, we could skip it instead of growing
task queue.
Should help with https://github.com/LadybirdBrowser/ladybird/issues/1647
If we end up in a situation where the navigable no longer has an active
window, we can't perform navigation or many other navigable operations.
These are all ad-hoc, since the navigables spec is basically all written
as if there's always an active window. Unfortunately, the active window
comes from the active document's browsing context, which is a nullable
concept even in the spec, so we do need to deal with null here.
This removes all the locally reproducible crashes when running WPT over
the legacy Japanese encoding directory on my computer.
Yes, this is a bit of a monkey patch, but it should be harmless since
we're (as I understand it) dealing with navigables that are still
hanging around with related tasks queued on them. Once all these tasks
have been completed, the navigables will go away anyway.
Because of the previous awkward factoring of Origin we had two
implementations of Origin serializing and creation. Move the
implementation of DOMURL::url_origin into URL::origin, and
instead use the implemenation of URL::Origin::serialize for
serialization (replacing URL::serialize_origin).
This happens to fix 8 URL subtests as the two implemenations had
diverged, and URL::serialize_origin was previously missing the spec
changes of: whatwg/url@eee49fd and whatwg/url@fff33c3
While Origin is defined in the HTML spec - this leaves us with quite an
awkward relationship as the URL spec makes use of AO's from what is
defined in the HTML spec.
To simplify this factoring, relocate Origin into LibURL.
