Before this change, a formatting context was responsible for layout of
absolutely positioned boxes whose FC root box was their parent (either
directly or indirectly). This only worked correctly when the containing
block of the absolutely positioned child did not escape the FC root.
This is because the width and height of an absolutely positioned box are
resolved based on the size of its containing block, so we needed to
ensure that the containing block's layout was completed before laying
out an absolutely positioned box.
With this change, the layout of absolutely positioned boxes is delayed
until the FC responsible for the containing block's layout is complete.
This has affected the way we calculate the static position. It is no
longer possible to ask the FC for a box's static position, as this FC's
state might be gone by the time the layout for absolutely positioned
elements occurs. Instead, the "static position rectangle" (a concept
from the spec) is saved in the layout state, along with information on
how to align the box within this rectangle when its width and height are
resolved.
FormattingContext::run() does not allow reentrancy, so it's safe to
save and access layout mode from FC object. This avoids need to drill it
through methods of a formatting context and makes it clear that this
value could never be changed after FC construction.
Root formatting context box is passed into constructor and saved in FC,
so it's possible to access it from there instead of passing the same
box into run().
You can now build with STYLE_INVALIDATION_DEBUG and get a debug stream
of reasons why style invalidations are happening and where.
I've rewritten this code many times, so instead of throwing it away once
again, I figured we should at least have it behind a flag.
This API is a relic from the time when it was important for objects to
have easy access to the Window, and to know it was the global object.
We now have more spec-related concepts like relevant_global_object and
current_global_object to pull the Window out of thin air.
Calls to `Document::set_needs_display()` and
`Paintable::set_needs_display()` now invalidate the display list by
default. This behavior can be changed by passing
`InvalidateDisplayList::No` to the function where invalidating the
display list is not necessary.
Use offset from ScrollFrame which is an actual value a box is shifted by
while painting.
Also change `update_paint_and_hit_testing_properties_if_needed()` to
refresh scroll frames state, because `getBoundingClientRect()` now
depends on them.
Fixes wrong file tree sidebar location and excessive layout
invalidations caused by some miscalculation on JS-side when wrong
bounding client rect is provided on Github PR pages like
https://github.com/LadybirdBrowser/ladybird/pull/1232/files
Sticky positioning is implemented by modifying the algorithm for
assigning and refreshing scroll frames. Now, elements with
"position: sticky" are assigned their own scroll frame, and their
position is refreshed independently from regular scroll boxes.
Refreshing the scroll offsets for sticky boxes does not require display
list invalidation.
A separate hash map is used for the scroll frames of sticky boxes. This
is necessary because a single paintable box can have two scroll frames
if it 1) has "position: sticky" and 2) contains scrollable overflow.
`BrowsingContext::m_parent` has been removed from the spec,
and previously `m_parent` was always null.
`BrowsingContext::is_top_level` was already always returning
true before because of that, and the updated spec algorithm
causes assertions to fail.
This fixes the following example:
```html
<a href="about:blank" target="test">a
<iframe name="test">
```
clicking the link twice no longer causes it to open in a new tab.
...if only the scroll offset is updated.
Currently, on any document with a large amount of content, the process
of building a display list is often more expensive than its
rasterization. This is because the amount of work required to build a
display list is proportional to the size of the paintable tree, whereas
rasterization only occurs for the portion visible in the viewport.
This change is the first step toward improving this process by caching
the display list across repaints when neither style nor layout requires
invalidation. This means that repainting while scrolling becomes
significantly less expensive, as we only need to reapply the scroll
offsets to the existing display list.
The performance improvement is especially visible on pages like
https://ziglang.org/documentation/master/ or
https://www.w3.org/TR/css-grid-2/
While introducing clip and scroll frame trees, I made a mistake by
assuming that the paintable tree includes boxes from nested navigables.
Therefore, this comment in the code was incorrect, and clip/scroll
frames were simply not assigned for iframes:
// NOTE: We only need to refresh the scroll state for traversables
// because they are responsible for tracking the state of all
// nested navigables.
As a result, anything with "overflow: scroll" is currently not
scrollable inside an iframe
This change fixes that by ensuring clip and scroll frames are assigned
and refreshed for each navigable. To achieve this, I had to modify the
display list building process to record a separate display list for each
navigable. This is necessary because scroll frame ids are local to a
navigable, making it impossible to call
`DisplayList::apply_scroll_offsets()` on a display list that contains
ids from multiple navigables.
For the SVG <use> element, we want to support loading HTML documents
that have a SVG element inside of it pointed to by the URL fragment.
In this situation we would need to fetch and parse the entire document
in SharedImageRequest (so that we can still cache the SVGs). Rename
SharedImageRequest to SharedResourceRequest to make the class a little
more generic for future usecases.
To avoid expensive lookups, we now cache a weak pointer from document to
the last known node navigable. Before using the cache, we validate that
the document is still the navigable's active document.
Navigables are re-used for navigations within the same tab. Its current
ownership of the cursor position is a bit ad-hoc, so nothing in the spec
indicates when to reset the cursor, nor do we manually do so. So when a
cursor update happens on one page, that cursor is retained on the next
page.
Instead, let's have the document own the cursor. Each navigation results
in a new document, thus we don't need to worry about resetting cursors.
This also makes many of the callsites feel nicer. We were previously
often going from the node, to the document, to the navigable, to the
cursor. This patch removes the navigable hop.
We explicitly stopped visting the map of documents to console clients in
commit 44659f2f2a to avoid keeping the
document alive. However, if nothing else visits the console clients, we
may set the top-level console client to a client that has been garbage
collected.
So instead of storing this map, just store the console client on the
document itself. This will allow the document to visit its client.
We were mistakenly executing the current node's script instead of the
document's pending parsing-blocking script.
This caused ~1000 WPT tests to time out, since we never ended up firing
a load event for XHTML pages that load multiple external scripts.
These methods were overriding properties specified by the EventInit
property bags in the constructor for WheelEvent and MouseEvent.
They appear to be legacy code and no longer relevant, as they would have
been used for ensuring natively dispatched events had the correct
properties --- This is now done in separate create methods, such as
MouseEvent::create_from_platform_event.
This fixes a couple WPT failures (e.g. in
/dom/events/Event-subclasses-constructors.html)
The first time Document learns its viewport size, we now suppress firing
of the resize event.
This fixes an issue on multiple websites that were not expecting resize
events to fire so early in the loading process.
Previously, unnecessary boundary checks were being done when
constructing the range objects used to represent find in page matches.
These checks are no longer performed leading to a significant speedup
when performing find in page queries on pages containing a lot of text.
The first step of the find in page algorithm is to walk the layout tree
of each document on the page and construct a list of strings against
which to search for matches.
Previously, this was being done for each new query, even when the
page content hadn't been updated. The output of this process is now
cached in the viewport node of the associated document. This ensures
that this process is no longer repeated unnceessarily.
And let the old shadow_root(), which was only supposed to be used by
bindings, be called shadow_root_for_bindings() instead.
This makes it much easier to read DOM code, and we don't have to worry
about when to use shadow_root_internal() or why.
Find in page will no longer match text that spans across block elements.
Previously, given the markup `WH<div>F</div>`, the query `WHF` would
find a match. We would now match `WH` and `F` separately, but not `WHF`.
Previously, the find in page function would fail to find text which was
split across multiple text nodes. For example, given the following
markup: `WH<span>F` the query `WHF` would previously fail to be
matched.
This is done by traversing all of the document's text nodes -
constructing a complete string to query against and keeping track of
the locations where that string is split across multiple nodes.
The spec doesn't explicitly forbid calling this when the document
doesn't have a node navigable, so let's handle that situation gracefully
by just returning an empty list of ancestors.
I hit this VERIFY somewhere on the web, but I don't know how to
reproduce it.
If the Document's navigable has been destroyed since we started this
timer, or it's no longer the active document of its navigable, we
shouldn't navigate to it.
The main intention of this change is to have a consistent look and
behavior across all scrollbars, including elements with
`overflow: scroll` and `overflow: auto`, iframes, and a page.
Before:
- Page's scrollbar is painted by Browser (Qt/AppKit) using the
corresponding UI framework style,
- Both WebContent and Browser know the scroll position offset.
- WebContent uses did_request_scroll_to() IPC call to send updates.
- Browser uses set_viewport_rect() to send updates.
After:
- Page's scrollbar is painted on WebContent side using the same style as
currently used for elements with `overflow: scroll` and
`overflow: auto`. A nice side effects: scrollbars are now painted for
iframes, and page's scrollbar respects scrollbar-width CSS property.
- Only WebContent knows scroll position offset.
- did_request_scroll_to() is no longer used.
- set_viewport_rect() is changed to set_viewport_size().
