This is the way.
On a more serious note, there's no reason to keep adding ref-counted
classes to LibWeb now that the majority of classes is GC'd - it only
adds the risk of discovering some cycle down the line, and forces us to
use handles as we can't visit().
(And BrowsingContextGroup had to come along for the ride as well.)
This solves a number of nasty reference cycles between browsing
contexts, history items, and their documents.
With the addition of the 'fetch params' struct, the single ownership
model we had so far falls apart completely.
Additionally, this works nicely for FilteredResponse's internal response
instead of risking a dangling reference.
Replacing the public constructor with a create() function also found a
few instances of a Request being stack-allocated!
We now implement the browsing context's "set active document" algorithm
from the spec, as well as the "discard" algorithm for browsing contexts
and documents.
We're still missing the lazy loading attribute handling, and once we hit
the navigation step, we fall back to totally ad-hoc behavior instead of
going all the way with a Fetch Request.
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.
Specifically HTMLIFrameElement and HTMLObjectElement. HTMLEmbedElement
will gain it automatically once it's also converted to inherit from
BrowsingContextContainer.
We will soon have two DOM nodes which contain nested browsing contexts:
HTMLIFrameElement and HTMLObjectElement. Only HTMLIFrameElement should
have its nested context created automatically upon insertion, so move
the invocation of that logic to HTMLIFrameElement.
Once we paint, it's way too late for this check to happen anyway.
Additionally, the spec's steps for retrieving the content document
assume that both the browsing context's active document and the
container's node document are non-null, which evidently isn't always the
case here, as seen by crashes on the SerenityOS 2nd and 3rd birthday
pages (I'm not sure about the details though).
Fixes#12565.
The "completely finish loading" algorithm (from the HTML spec) is
responsible for sending a "load" event to nested browsing context
containers (iframes).
This patch removes the old mechanism for sending "load" events, which we
had mistakenly kept around, causing two events to be sent instead of
one. :^)
This changes allows for nested browser contexts to be embedded in the
serialized JSON of their container element (like `iframe`) and enables
their inspection in the DOM Inspector.
