Some of the live HTMLCollection only ever contain children of their root
node. When we know that's the case, we can avoid doing a full subtree
traversal of all descendants and only visit children.
This cuts the ECMA262 spec loading time by over 10 seconds. :^)
Before this change, LayoutState essentially had a Vector<UsedValues*>
resized to the exact number of layout nodes in the current document.
When a nested layout is performed (to calculate the intrinsic size of
something), we make a new LayoutState with its own Vector. If an entry
is missing in a nested LayoutState, we check the parent chain all the
way up to the root.
Because each nested LayoutState had to allocate a new Vector with space
for all layout nodes, this could get really nasty on very large pages
(such as the ECMA262 specification).
This patch replaces the Vector with a HashMap. There's now a small cost
to lookups, but what we get in return is the ability to handle huge
layout trees without spending eternity in page faults.
Before this, any style change that mutated a property we consider
"layout-affecting" would trigger a complete teardown and rebuild of the
layout tree.
This isn't actually necessary for the vast majority of CSS properties,
so this patch makes the invalidation a bit finer, and we now only
rebuild the layout tree when the CSS display property changes.
For other layout-affecting properties, we keep the old layout tree (if
we have one) and run the layout algorithms over that once again.
This is significantly faster, since we don't have to run all the CSS
selectors all over again.
There's no need for this to require a DeprecatedString - the method it
wraps around already only expects a StringView. This allows passing a
String instance without any conversion.
This lets elements figure out if they're visible within the viewport or
not, so they take appropriate action.
Fixes the issues with animations not starting until the viewport was
resized or scrolled.
If something else has already caused a layout, there's no need to force
a new relayout when the layout timer fires.
This avoids a lot of redundant work on many pages. :^)
The "browsing context container" concept in the HTML spec has been
replaced with "navigable container". Renaming this is the first step of
many towards implementing the new world.
Co-authored-by: Aliaksandr Kalenik <kalenik.aliaksandr@gmail.com>
The spec defines a Permissions Policy to control some browser behaviors
on a per-origin basis. Management of these permissions live in their own
spec: https://w3c.github.io/webappsec-permissions-policy/
This implements a somewhat ad-hoc Permissions Policy for autoplaying
media elements. We will need to implement the entire policy spec for
this to be more general.
This ports MouseEvent, UIEvent, WheelEvent, and Event to new String.
They all had a dependency to T::create() in
WebDriverConnection::fire_an_event() and therefore had to be ported in
the same commit.
This makes selector matching significantly faster by not forcing us to
convert from FlyString to DeprecatedFlyString when matching class
selectors. :^)
The name "initial containing block" was wrong for this, as it doesn't
correspond to the HTML element, and that's specifically what it's
supposed to do! :^)
In about:blank documents, we should use the browsing context's creator
URL as the base URL, if it exists and there is no <base> element.
This means that any about:blank frames will have URLs parse relative to
their parent frame's URL.
Fixes#17394.
Because of interdependencies between DOM::Event and UIEvents::MouseEvent
to template function fire_an_event() in WebDriverConnection.cpp, the
commit: 'LibWeb: Make factory methods of UIEvents::MouseEvent fallible'
have been squashed into this commit.
