Previously Selection.extend() used only the relative node order to decide which
direction to extend the selection. This leads to incorrect behaviour if
both the existing and new boundary points are within the same DOM node
and the selection direction is reversed.
This change fixes all the failing subtests in the WPT extend-* test
suites.
(cherry picked from commit 18ade57ae96da05c845582ab03b588c55c1e6633)
The "isCollapsed" attribute on a selection must "return true if and only
if the anchor and focus are the same".
In addition to checking that the anchor and focus belonged to the same
DOM node, we now also check that they refer to the same position within
the node.
With this change Ladybird passes all the subtests in the "isCollapsed"
WPT suite.
https://wpt.live/selection/isCollapsed.html
(cherry picked from commit fadb14d31d0d3127e80121ac695fe839908efaa1)
There was no need to use FlyString for error messages, and it just
caused a bunch of churn since these strings typically only existed
during the lifetime of the error.
(cherry picked from commit 175f3febb8037a440d4ead7347d3266ee3d345e1;
minorly amended to fix conflict in WebSocket.cpp due to serenity
not having the adapter class removal in LadybirdBrowser/ladybird#1671)
This matches the behavior of all major engines, and is covered by
hundreds of subtests in WPT.
Spec PR: https://github.com/w3c/selection-api/pull/342
(cherry picked from commit 13bd52249d3fe674b8c11049eb66a305e058ee6f)
If the anchor and focus nodes are not within the same document, we can't
use them for a selection range.
Found by Domato.
(cherry picked from commit 416c4788763baa778465d1d004080d322462c0bf)
This was resulting in a whole lot of rebuilding whenever a new IDL
interface was added.
Instead, just directly include the prototype in every C++ file which
needs it. While we only really need a forward declaration in each cpp
file; including the full prototype header (which itself only includes
LibJS/Object.h, which is already transitively brought in by
PlatformObject) - it seems like a small price to pay compared to what
feels like a full rebuild of LibWeb whenever a new IDL file is added.
Given all of these includes are only needed for the ::initialize
method, there is probably a smart way of avoiding this problem
altogether. I've considered both using some macro trickery or generating
these functions somehow instead.
This commit introduces a WEB_SET_PROTOTYPE_FOR_INTERFACE macro that
caches the interface name in a local static FlyString. This means that
we only pay for FlyString-from-literal lookup once per browser lifetime
instead of every time the interface is instantiated.
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. :^)
Stop worrying about tiny OOMs. Work towards #20449.
While going through these, I also changed the function signature in many
places where returning ThrowCompletionOr<T> is no longer necessary.
Note that as of this commit, there aren't any such throwers, and the
call site in Heap::allocate will drop exceptions on the floor. This
commit only serves to change the declaration of the overrides, make sure
they return an empty value, and to propagate OOM errors frm their base
initialize invocations.
Before this patch, we were expressing the current selection as a range
between two points in the layout tree. This was a made-up concept I
called LayoutRange (2x LayoutPosition) and as it turns out, we don't
actually need it!
Instead, we can just use the Selection API from the Selection API spec.
This API expresses selection in terms of the DOM, and we already had
many of the building blocks implemented.
To ensure that selections get visually updated when the underlying Range
of an active Selection is programmatically manipulated, Range now has
an "associated Selection". If a range is updated while associated with
a selection, we recompute layout tree selection states and repaint the
page to make it user-visible.
This needs to happen before prototype/constructor intitialization can be
made lazy. Otherwise, GC could run during the C++ constructor and try to
collect the object currently being created.
This will make it easier to support both string types at the same time
while we convert code, and tracking down remaining uses.
One big exception is Value::to_string() in LibJS, where the name is
dictated by the ToString AO.
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 :^)
These classes only needed Window to get at its realm. Pass a realm
directly to construct Crypto, Encoding, HRT, IntersectionObserver,
NavigationTiming, Page, RequestIdleCallback, Selection, Streams, URL,
and XML classes.
