Selection.extend() can keep an old anchor that is no longer orderable
with the new focus after a selected shadow host is detached. Collapse
to the new focus in that case and avoid comparing boundary points from
different shadow-including roots.
Add reduced crash coverage for extending a selection after detaching
the shadow host that held the old anchor.
Problem: Selection.containsNode() crashes when the selection’s range
has boundary points in a tree that’s not connected — such as a shadow
tree whose host was removed. We also call that function internally for
content-visibility:auto elements during rendering — so it can cause a
page to crash even when the page itself doesn’t use the Selection API.
Cause: When a shadow host is removed, a selection range whose boundary
points are inside its shadow tree isn’t adjusted: live-range adjustment
matches ranges by regular-tree descendant and doesn’t reach into shadow
trees. The range is left pointing into the detached shadow tree.
contains_node() verifies only the passed node against the document — not
the range — then runs a boundary-point comparison that requires both
sides to share a shadow-including root.
Fix: Make contains_node() also confirm the range’s boundary points are
rooted at the document. If not, then return false — because a node can’t
be contained in a selection whose range is in a different tree.
Fixes https://github.com/LadybirdBrowser/ladybird/issues/9469
The Paintable tree and its supplemental painting data structures were
GC allocated because that was the easiest way to manage it and avoid
leaks introduced by ref cycles. This included the Paintable subclasses
themselves plus StackingContext, ChromeWidget, Scrollbar, ResizeHandle,
and scroll-frame state.
We are now trying to reduce GC allocation churn on layout and painting
updates, so keeping this short-lived rendering tree outside the JS heap
is a better fit. Move Paintable to RefCountedTreeNode, make painting
helpers ref-counted or weakly reference Paintables, and update the
layout and event-handler call sites to use RefPtr/WeakPtr ownership.
Previously, the LibWeb bindings generator would output multiple per
interface files like Prototype/Constructor/Namespace/GlobalMixin
depending on the contents of that IDL file.
This complicates the build system as it means that it does not know
what files will be generated without knowledge of the contents of that
IDL file.
Instead, for each IDL file only generate a single Bindings/<IDLFile>.h
and Bindings/<IDLFile>.cpp.
Previously if you had a selection and you pressed the left/right arrow
key it would collapse the selection *and* perform the movement. This is
not how most text editors work and felt unnatural.
We were mimicking Firefox' behavior that whenever a programmatic change
to an <input>'s or <textarea>'s selection happened, the new selection
focus is brought into view by scrolling. Currently we run a layout
update synchronously for that to make sure we have the fragment's
correct dimensions, which caused a significant performance regression in
Speedometer.
Since this is non-standard behavior, let's mimic Chromium instead which
does not scroll at all - only for direct user initiated input such as
typing.
Relevant issues:
* https://github.com/whatwg/html/issues/6217
* https://bugzilla.mozilla.org/show_bug.cgi?id=232405
* https://issues.chromium.org/issues/41081857
When the mouse is dragged from inside a scrollable container to outside
of it, we now automatically scroll the container so the selection can be
extended. Scroll speed scales with the distance past the scrollport
edge, capped at a maximum. Edges close to the viewport boundary get a
wider activation zone so the speed ramp works predictably even when the
mouse has limited room to move.
The logic is encapsulated in AutoScrollHandler, which EventHandler
creates lazily on mouse selection start.
If a node with `contenteditable=true/plaintextonly` is the child of an
editable node or an editing host, we should make it editable instead of
an editing host. This effectively merges nested editing hosts together,
which is how other browsers deal with this as well.
Gains us 5 WPT subtest passes in `editing`.
And make it a DOM::Node, not DOM::Element. This makes everything flow
much better, such as spec texts that explicitly mention "focused area"
as the fact that we don't necessarily need to traverse a tree of
elements, since a Node can be focusable as well.
Eventually this will need to be a struct with a separate "focused area"
and "DOM anchor", but this change will make it easier to achieve that.
We were constraining the focusing behavior for editing hosts a bit too
much; regardless of how the selection changed, if the start container is
inside an editing host and it's currently not focused, we should focus
it. This fixes focus stealing by other elements that set a selection
inside an editing host on a click event, for example.
Before this change, we were going through the chain of base classes for
each IDL interface object and having them set the prototype to their
prototype.
Instead of doing that, reorder things so that we set the right prototype
immediately in Foo::initialize(), and then don't bother in all the base
class overrides.
This knocks off a ~1% profile item on Speedometer 3.
We were using the anchor_node() as the boundary point node when
collapsing a selection, but the spec tells us to use the start and end
boundary point nodes.
Resulting in a massive rename across almost everywhere! Alongside the
namespace change, we now have the following names:
* JS::NonnullGCPtr -> GC::Ref
* JS::GCPtr -> GC::Ptr
* JS::HeapFunction -> GC::Function
* JS::CellImpl -> GC::Cell
* JS::Handle -> GC::Root
The main motivation behind this is to remove JS specifics of the Realm
from the implementation of the Heap.
As a side effect of this change, this is a bit nicer to read than the
previous approach, and in my opinion, also makes it a little more clear
that this method is specific to a JavaScript Realm.
