Both Element and DOMTokenList are GC-allocated objects so they can just
mark each other instead of using the old strong/weak pattern we use in
ref-counting ownership models.
According to the spec we should return removed attribute, but the old
implementation returned nullptr instead.
Now we return the element's removed attribute.
This patch adds methods for querying element by namespace and
local name.
These methods are defined by the spec for internal
usage, but weren't implemented in LibWeb yet.
This fixes a few sizing issues too. The page size is now correct in most
cases! \o/
We get to remove some of the `to_type<>()` shenanigans, though it
reappears in some other places.
GCPtr can be null so it's not safe to assign it to a NonnullGCPtr unless
you know it to be non-null.
This exposed a number of wrong uses in LibWeb which had to be fixed as
part of this change.
This constructor was easily confused with a copy constructor, and it was
possible to accidentally copy-construct Objects in at least one way that
we dicovered (via generic ThrowCompletionOr construction).
This patch adds a mandatory ConstructWithPrototypeTag parameter to the
constructor to disambiguate it.
...and also for hit testing, which is involved in most of them.
Much of this is temporary conversions and other awkwardness, which
should resolve itself as the rest of LibWeb is converted to these new
types. Hopefully. :thousandyakstare:
Note that js_rope_string() has been folded into this, the old name was
misleading - it would not always create a rope string, only if both
sides are not empty strings. Use a three-argument create() overload
instead.
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 :^)
The ::placeholder pseudo element was added in commit 1fbad9c, but the
total number of pseudo elements was not updated. Instead of this manual
bookkeeping, add a dummy value at the end of the enumeration for the
count.
This getter and setter were previously labelled as a "hack" and used to
disable style invalidation on attribute changes during the HTML parsing
phase (as it caused big sites's loading to be slow). These functions
are currently not used, so they can be removed:^)
These lambdas were marked mutable as they captured a Ptr wrapper
class by value, which then only returned const-qualified references
to the value they point from the previous const pointer operators.
Nothing is actually mutating in the lambdas state here, and now
that the Ptr operators don't add extra const qualifiers these
can be removed.
These are required for hit testing the document in Google Docs. If they
aren't defined, the Google Docs hit test code will add undefined to
certain values, causing them to turn into NaN. This causes NaNs to
propagate through their hit test code, which eventually makes it
infinitely loop.
C++20 can automatically synthesize `operator!=` from `operator==`, so
there is no point in writing such functions by hand if all they do is
call through to `operator==`.
This fixes a compile error with compilers that implement P2468 (Clang
16 currently). This paper restores the C++17 behavior that if both
`T::operator==(U)` and `T::operator!=(U)` exist, `U == T` won't be
rewritten in reverse to call `T::operator==(U)`. Removing `!=` operators
makes the rewriting possible again.
See https://reviews.llvm.org/D134529#3853062
When parsing relative URLs, we have to check the first <base href> in
tree order (if one is available). This was getting *very* costly on
large DOMs with many relative urls.
This patch avoids all that repeated traversal by letting Document cache
the first <base href> and invalidating the cache whenever a <base>
element is added/removed/edited in the DOM.
The browser was stuck doing this for a *very* long time when loading
the ECMA-262 spec, and this removes that problem entirely.
