Previously, we determined the positions of glyphs for each text run at
the time of painting, which constituted a significant portion of the
painting process according to profiles. However, since we already go
through each glyph to figure out the width of each fragment during
layout, we can simultaneously gather data about the position of each
glyph in the layout phase and utilize this information in the painting
phase.
I had to update expectations for a couple of reference tests. These
updates are due to the fact that we now measure glyph positions during
layout using a 1x font, and then linearly scale each glyph's position
to device pixels during painting. This approach should be acceptable,
considering we measure a fragment's width and height with an unscaled
font during layout.
The Inspector will have an <input> element to execute user-provided JS.
This adds an IDL method and IPC to forward that JS from the Inspector
WebView to the Inspector client.
The spec states that if an input key would insert a numerical character
if it were pressed without a modifier, then the keyCode should be that
of the numerical character. For example, the keyCode for a dollar sign
should be that of the number 4.
Further, we should implement the optional fixed virtual key codes.
Otherwise, our implementation would give e.g. the double quote a keyCode
value of 38, which is the same as the up arrow key.
We need to give pages the opportunity to intercept keydown events and
potentially stop them from propagating. Otherwise, for example, pressing
an arrow key in an <input> element is not observable via script.
The return value of fire_keyboard_event is meant to indicate whether the
event should continue propagating (true) or halt (false). This exactly
matches the return value of dispatch_event, so by negating the result,
we are propagating events we shouldn't, and not propagating events we
should.
We currently fire the change event on <input> elements when they lose
focus. The spec allows for us to also fire the event when changes are
"committed", so long as such an action makes sense for the input type.
This patch detects when the return key is entered in an <input> element
and uses that as the commit action for text-related types. If no change
has occurred since the last commit, no change event is fired.
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.
