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.
