These classes only needed Window to get at its realm. Pass a realm
directly to construct DOM and WebIDL classes.
This change importantly removes the guarantee that a Document will
always have a non-null Window object. Only Documents created by a
BrowsingContext will have a non-null Window object. Documents created by
for example, DocumentFragment, will not have a Window (soon).
This incremental commit leaves some workarounds in place to keep other
parts of the code building.
Previously we only considered an element disabled if it was an <input>
element with the disabled attribute, but there's way more elements that
apply with more nuanced disabled/enabled rules.
One edge case is left as a TODO() for now, since I'm not entirely sure
how to construct an element to those specifications.
With this patch, we can now run the Speedometer benchmark! :^)
When querying the HTML element (in strict mode) or the BODY element
(in quirks mode), we return the viewport dimensions.
Layout doesn't change the size of the viewport, so we can actually
reorder the steps here and avoid performing layout in some cases.
This removes a bunch of synchronous layouts on pages with reCAPTCHA.
Unlike ensure_web_prototype<T>(), the cached version doesn't require the
prototype type to be fully formed, so we can use it without including
the FooPrototype.h header. It's also a bit less verbose. :^)
This is a monster patch that turns all EventTargets into GC-allocated
PlatformObjects. Their C++ wrapper classes are removed, and the LibJS
garbage collector is now responsible for their lifetimes.
There's a fair amount of hacks and band-aids in this patch, and we'll
have a lot of cleanup to do after this.
Each of these strings would previously rely on StringView's char const*
constructor overload, which would call __builtin_strlen on the string.
Since we now have operator ""sv, we can replace these with much simpler
versions. This opens the door to being able to remove
StringView(char const*).
No functional changes.
The goal here is to move the parser-internal classes into this namespace
so they can have more convenient names without causing collisions. The
Parser itself won't collide, and would be more convenient to just
remain `CSS::Parser`, but having a namespace and a class with the same
name makes C++ unhappy.
There were two main issues with these functions:
1. They were not updating layout before inspecting metrics.
2. They were not returning viewport metrics for the root and body
elements when appropriate.
If the font resource finishes loading we need to make sure the element
using it gets a chance to re-layout, even if the font-family property
didn't change.
When parsing the "style" attribute on elements, we'd previously ask the
CSS parser for a PropertyOwningCSSStyleDeclaration. Then we'd create a
new ElementCSSInlineStyleDeclaration and transfer the properties from
the first object to the second object.
This patch teaches the parser to make ElementCSSInlineStyleDeclaration
objects directly.
I came across some websites that change an elements CSS "opacity" in
their :hover selectors. That caused us to relayout on hover, which we'd
like to avoid.
With this patch, we now check if a property only affects the stacking
context tree, and if nothing layout-affecting has changed, we only
invalidate the stacking context tree, causing it to be rebuilt on next
paint or hit test.
This makes :hover { opacity: ... } rules much faster. :^)
We were hanging on to element inline style, even after the style
attribute was removed. This made inline style sticky and impossible to
remove. This patch fixes that. :^)
This was causing us to miss layout invalidations. With this fixed, we
can remove the invalidation from Element::recompute_style() along with
the associated FIXME.
Thanks to Idan for spotting this! :^)
Use the new CSS::property_affects_layout() helper to figure out if we
actually need to perform a full relayout after recomputing style.
There are three tiers of required invalidation after an element receives
new style: none, repaint only, or full relayout.
This avoids the need to rebuild the layout tree (and perform layout on
it) when trivial properties like "color" etc are changed.
Let's make it very clear that these are *computed* values, and not at
all the specified values. The specified values are currently discarded
by the CSS cascade algorithm.
