In order for same-origin NavigableContainers (iframe, frame, embed, ...)
and window.open() WindowProxies to have the proper JS access to their
embedder/opener, we need to host multiple top level traversables in the
same WebContent process. As a first step, make WebContent::PageHost hold
a HashMap of PageClient objects, each holding their own Web::Page that
represents a TraversableNavigable's API surface with the UI process.
This removes a performance problem where we'd convert the style sheet's
default namespace from DeprecatedFlyString to FlyString once per rule
during selector matching.
The conversion now happens once, during CSS parse. It should eventually
be removed from there as well, but one step at a time. :^)
`<iframe>`s only potentially delay the load event when their
`current_navigation_was_lazy_loaded` flag is false, so let's wire that
up to the flag's setter, and actually call it!
Four elements match the "potentially delay the load event" check in the
spec: `<embed>`, `<frame>`, `<iframe>`, and `<object>`. These four are
the same set of elements that are NavigableContainers (or will be once
we implement them) so let's put this logic there.
Note that other things can delay the load event, this is just the name
the spec gives to this particular behaviour.
`<iframe>` and `<img>` tags share the same spec for several aspects of
lazy-loading: how the `loading` attribute works, the "will lazy load
element" steps, and a member for storing the lazy-load resumption
steps. So let's share the implementation by using a base class.
This mostly involves moving things around. However, we also change the
`start_intersection_observing_a_lazy_loading_element()` method to take
a LazyLoadingElement, and operate on one, instead of always casting to
HTMLImageElement.
We do unfortunately have to do some shenanigans to make the cast work,
by adding a virtual function stub in DOM::Element.
If `SkipStackingContext` is returned we also need to restore saved
painter state because corresponding pop_stacking_context command that
is supposed to do that will be skipped.
Fixes https://github.com/SerenityOS/serenity/issues/22092
We currently create a shadow tree once for each DOM element that renders
with a shadow tree (e.g. <input>, <details>). If such an element is
removed from the DOM, we must remove its shadow tree. Otherwise, the
shadow tree will refer to the old document in perpetuity.
If the node is added back to a DOM, then recreate the shadow tree.
AbstractBrowsingContext has a subclass RemoteBrowsingContext without a
visit_edges() override (and it doesn't really need one). But currently,
we rely on subclasses visiting AbstractBrowsingContext's opener BC.
This adds a visit_edges() to AbstractBrowsingContext to explicitly visit
the opener BC itself.
This change ensures that the GPU painting executor follows the pattern
of the CPU executor, where the state is stored for each stacking
context, but a painter is created only for those with opacity.
Fixes crashing on apple.com because now save() and restore() are called
on correct painters.
Instead of allocating these in a mixture of ways, we now always put
them on the malloc heap, and keep an intrusive linked list of them
that we can iterate for GC marking purposes.
This change introduces a texture cache for immutable bitmaps in the
GPU painter. The cache is persisted across page repaints, so now, on
page scroll repaint, in many cases, we won't need to upload any new
textures. Also, if the same image is painted more than once on a page,
its texture will only be uploaded once.
Generally, the GPU painter works much faster with this change on all
pages that have images.
Before this change, we used Gfx::Bitmap to represent both decoded
images that are not going to be mutated and bitmaps corresponding
to canvases that could be mutated.
This change introduces a wrapper for bitmaps that are not going to be
mutated, so the painter could do caching: texture caching in the case
of GPU painter and potentially scaled bitmap caching in the case of CPU
painter.
The `page_did_request_scroll_to` API takes a CSS position, and thus
callers should not scale to device pixels before invoking it. Instead,
align this API with (most) other PageHost APIs which scale to device
pixels before sending the corresponding IPC message.
In the AppKit chrome, convert the provided device pixel position to a
widget position.
These wrappers will make it much easier to do various operations on the
different ArrayBuffer-related classes in LibWeb compared to the current
solution, which is to just accept a Handle<Object> everywhere (and use
"any" in the *.idl files).
Co-Authored-By: Matthew Olsson <mattco@serenityos.org>
