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.
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.
Prior to this change, we iterated through all fragments within each
PaintableWithLines to resolve the relative position offset. This
happened before transferring the fragments to their corresponding
inline paintables.
With this change, we significantly reduce amount of work by attempting
to resolve relative position offsets only for those contained within
inline paintables.
Performance improvement on https://html.spec.whatwg.org/
Now, instead of resolving "transform" and "transform-origin" during the
construction of the stacking context tree, we do so during the layout
commit.
This is part of a refactoring effort to make the paintable tree
independent from the layout tree.
Now, we will evenly distribute the remaining free space across tracks
using the auto max-tracks sizing function, exactly as the specification
states. Many tests are affected, but they are not visually broken.
Fixes https://github.com/SerenityOS/serenity/issues/22798
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.
