This change makes WebGL to use LibGL only in SerenityOS, and the
platform's OpenGL driver in Ladybird if it is available.
This is implemented by introducing wrapper class between WebGL and
OpenGL calls. This way it will also be possible to provide more
complete support in Ladybird even if we don't yet have all needed
calls implemented in LibGL.
For now, the wrapper class makes all GL calls virtual. However, we
can get rid of this and implement it at compile time in case of
performance problems.
In the cases where spec authors have us directly interact with promises
in a task source context, we need to prepare the backup settings object
stack as well as push an actual execution context to the JS VM.
This prevents goal conditions that rely on tasks that are currently in
flight on the task queue (or were just submitted) from blocking the
event loop until an IPC event fires to kick the native event loop.
This involves passing the UserNavigationInvolvement from each form
associated element that triggers a submit through to the methods that
perform the actual navigation. While here, refactor HTMLFormElement to
use the new Bindings::NavigationHistoryBehavior enum.
The one current caller of this function always defers microtask
checkpoints before calling wait_for_all, ensuring that the promise
accept/reject handlers will always be called later in the Web event loop
processing. We need to store all the state for the closures in a heap
allocated object with HeapFunctions to keep it around while there are
still promises to resolve.
We need to make sure that the given target realm is at the top of the
VM's execution context stack before doing any JS object construction
based on the data in our serialized buffer.
This refactoring makes WebContent less aware of LibWeb internals.
The code that initializes paint recording commands now resides in
`Navigable::paint()`. Additionally, we no longer need to reuse
PaintContext across iframes, allowing us to avoid saving and restoring
its state before recursing into an iframe.
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
Previously, constructing a `UnsignedBigInteger::from_base()` could
produce an incorrect result if the input string contained a valid
Base36 digit that was out of range of the given base. The same method
would also crash if the input string contained an invalid Base36 digit.
An error is now returned in both these cases.
Constructing a BigFraction from string is now also fallible, so that we
can handle the case where we are given an input string with invalid
digits.
Switch over from deprecated_attribute to attribute, and reuse the result
of this lookup for both checking whether that attribute exists - and for
retrieving the value of that attribute when we need it.
Instead of spawning these processes from the WebContent process, we now
create them in the Browser chrome.
Part 1/N of "all processes are owned by the chrome".
We have two known PlatformObjects that need to implement some of the
behavior of LegacyPlatformObjects to date: Window, and HTMLFormElement.
To make this not require double (or virtual) inheritance of
PlatformObject, move the behavior of LegacyPlatformObject into
PlatformObject. The selection of LegacyPlatformObject behavior is done
with a new bitfield of feature flags instead of a dozen virtual
functions that return bool. This change simplifies every class involved
in the diff with the notable exception of Window, which now needs some
ugly const casts to implement named property access.
Many sites load application/json and application/ld+json
content with script elements, so this debug line shows
up on a lot of sites and is not informative.
Dispatching events can cause arbitrary JS to run, which could cause the
event loop to be re-entered, or even post another message to the same
message port.
