Instead of using Core::EventLoop and Core::Timer directly, LibWeb now
goes through a Web::Platform abstraction layer instead.
This will allow us to plug in Qt's event loop (and QTimer) over in
Ladybird, to avoid having to deal with multiple event loops.
This is a monster patch that turns all EventTargets into GC-allocated
PlatformObjects. Their C++ wrapper classes are removed, and the LibJS
garbage collector is now responsible for their lifetimes.
There's a fair amount of hacks and band-aids in this patch, and we'll
have a lot of cleanup to do after this.
This removes the requirement of having a global object that actually
inherits from JS::GlobalObject, which is now a perfectly valid scenario.
With the upcoming removal of wrapper objects in LibWeb, the HTML::Window
object will inherit from DOM::EventTarget, which means it cannot also
inherit from JS::GlobalObject.
This overrides the JS host hooks to follow the spec for queuing
promises, making/calling job callbacks, unhandled promise rejection
handling and FinalizationRegistry queuing.
This also allows us to drop the on_call_stack_emptied hook in
Document::interpreter().
The environment settings object is effectively the context a piece of
script is running under, for example, it contains the origin,
responsible document, realm, global object and event loop for the
current context. This effectively replaces ScriptExecutionContext, but
it cannot be removed in this commit as EventTarget still depends on it.
https://html.spec.whatwg.org/multipage/webappapis.html#environment-settings-object
This patch adds the "has a rendering opportunity" concept from the spec
to BrowsingContext and uses it to filter out contexts that are unable
to render right now when doing the event loop's rendering updates.
Note that we actually consider all contexts to have a rendering
opportunity at all times right now. Coming up with reasons to avoid
rendering is left as a FIXME. :^)
The ideal solution here is to implement a more spec-compliant event
loop, but while we get all the pieces in place for that, this at least
makes the HTML event loop a bit more responsive since it never has to
wait for a 16ms timer to fire.
This doesn't follow the exact spec steps but instead simply makes a
nested Core::EventLoop and spins it while a periodic timer tests the
goal condition.
Since we can't simply give HTML::EventLoop control of the whole program,
we have to integrate with Core::EventLoop.
We do this by having a single-shot 0ms Core::Timer that we start when
a task is added to the queue, and restart after processing the queue and
there are still tasks in the queue.
This patch attaches a HTML::EventLoop to the main thread JS::VM used
for JavaScript bindings in the web engine.
The goal here is to model the various task scheduling mechanisms of the
HTML specification.
