With this change, elements that want to receive viewport rect updates
will need to register on document instead of the browsing context.
This change solves the problem where a browsing context for a document
is guaranteed to exist only while the document is active so browsing
context might not exit by the time DOM node that want to register is
constructed.
This is a part of preparation work before switching to navigables where
this issue becomes more visible.
Using `Core::Timer` that doesn't implicitly convert callback to
`JS::SafeFunction` fixes the bug when `BrowsingContext` is never
destroyed because of cyclic dependency between callback and
`BrowsingContext`.
This lets elements figure out if they're visible within the viewport or
not, so they take appropriate action.
Fixes the issues with animations not starting until the viewport was
resized or scrolled.
The "browsing context container" concept in the HTML spec has been
replaced with "navigable container". Renaming this is the first step of
many towards implementing the new world.
Co-authored-by: Aliaksandr Kalenik <kalenik.aliaksandr@gmail.com>
These will need to float around more than they're currently able to.
Put them on the GC heap to prepare for that.
Co-authored-by: Aliaksandr Kalenik <kalenik.aliaksandr@gmail.com>
In about:blank documents, we should use the browsing context's creator
URL as the base URL, if it exists and there is no <base> element.
This means that any about:blank frames will have URLs parse relative to
their parent frame's URL.
Fixes#17394.
...and also for hit testing, which is involved in most of them.
Much of this is temporary conversions and other awkwardness, which
should resolve itself as the rest of LibWeb is converted to these new
types. Hopefully. :thousandyakstare:
We have a new, improved string type coming up in AK (OOM aware, no null
state), and while it's going to use UTF-8, the name UTF8String is a
mouthful - so let's free up the String name by renaming the existing
class.
Making the old one have an annoying name will hopefully also help with
quick adoption :^)
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!
