`<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.
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.
Ideally we would not create a layout node at all for these elements so
that every layout node would always have a paintable associated with it.
But for now, to fix the crash, just leave a FIXME and special case this
element.
Also leave a VERIFY to make it easier to debug this type of crash in the
future.
Fixes a crash seen on codecov.io for my 'patch' project.
It's perfectly possible for JavaScript to call unobserve() on an element
that hasn't been observed. Let's stop asserting if that happens. :^)
Fixes#22020
Most elements don't have pseudo elements with CSS custom properties.
By only allocating this data structure when it's used, we can shrink
most elements by 208 bytes each. :^)
Most DOM nodes don't have registered mutation observers, so let's put
the metadata about them behind an OwnPtr to save space in the common
case.
Saves 16 bytes per DOM node that doesn't have registered observers.
With this change, we now have ~1200 CellAllocators across both LibJS and
LibWeb in a normal WebContent instance.
This gives us a minimum heap size of 4.7 MiB in the scenario where we
only have one cell allocated per type. Of course, in practice there will
be many more of each type, so the effective overhead is quite a bit
smaller than that in practice.
I left a few types unconverted to this mechanism because I got tired of
doing this. :^)
This will be required for propagating the current animation time to all
relevant timelines, which each propagate that time to all of their
relevant animations.
No IDL file pulls in these requiring DeprecatedString support, so we
are now able to remove these functions! :^)
Also leave a FIXME while we are at it, as ideally this function would
take an Optional<FlyString> - but the IDL generator does not currently
support this.
This is the API for NamedNodeMap which we are wanting to eventually use
instead of taking a StringView. Currently we just end up deferring to
the StringView versions of these functions, but at some stage in the
future, this will allow us to have O(1) comparison when making attribute
lookups.
In the meantime, the advantage of this API is that it makes it much less
awkward to use than the StringView variant when you have an
Optional<FlyString> namespace to pass through.
