Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-10-19 15:43:20 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Libraries/LibWeb/Layout/LayoutState.cpp

675 lines
33 KiB
C++
Raw Normal View History

LibWeb: Start making our layout system "transactional" This patch adds a map of Layout::Node to FormattingState::NodeState. Instead of updating layout nodes incrementally as layout progresses through the formatting contexts, all updates are now written to the corresponding NodeState instead. At the end of layout, FormattingState::commit() is called, which transfers all the values from the NodeState objects to the Node. This will soon allow us to perform completely non-destructive layouts which don't affect the tree. Note that there are many imperfections here, and still many places where we assign to the NodeState, but later read directly from the Node instead. I'm just committing at this stage to make subsequent diffs easier to understand.
2022-02-20 15:51:24 +01:00
/*
Meta: Update my e-mail address everywhere
2024-10-04 13:19:50 +02:00
* Copyright (c) 2022-2024, Andreas Kling <andreas@ladybird.org>
LibWeb: Make use of transform-box when calculating transforms We don't currently calculate the fill- or stroke-boxes of SVG elements, so for now we use the content- and border-boxes respectively, as those are the closest equivalents. The test will need updating when we do support them. Also, the test is a screenshot because of rendering differences when applying transforms: a 20px box does not get painted the same as a 10px box scaled up 2x. Otherwise that would be the more ideal form of test.
2024-01-26 15:56:25 +00:00
* Copyright (c) 2024, Sam Atkins <atkinssj@serenityos.org>
LibWeb: Replace InlinePaintable with PaintableWithLines created per line InlinePaintable was an ad-hoc paintable type required to support the fragmentation of inline nodes across multiple lines. It existed because there was no way to associate multiple paintables with a single layout node. This resulted in a lot of duplicated code between PaintableBox and InlinePaintable. For example, most of the CSS properties like background, border, shadows, etc. and hit-testing are almost identical for both of them. However, the code had to be duplicated to account for the fact that InlinePaintable creates a box for each line. And we had quite many places that operate on paintables with a code like: ``` if (box.is_paintable_box()) { // do something } else (box.is_inline_paintable()) { // do exactly the same as for paintable box but using InlinePaintable } ``` This change replaces the usage of `InlinePaintable` with `PaintableWithLines` created for each line, which is now possible because we support having multiple paintables per layout node. By doing that, we remove lots of duplicated code and bring our implementation closer to the spec.
2024-10-13 21:29:47 +02:00
* Copyright (c) 2024, Aliaksandr Kalenik <kalenik.aliaksandr@gmail.com>
LibWeb: Start making our layout system "transactional" This patch adds a map of Layout::Node to FormattingState::NodeState. Instead of updating layout nodes incrementally as layout progresses through the formatting contexts, all updates are now written to the corresponding NodeState instead. At the end of layout, FormattingState::commit() is called, which transfers all the values from the NodeState objects to the Node. This will soon allow us to perform completely non-destructive layouts which don't affect the tree. Note that there are many imperfections here, and still many places where we assign to the NodeState, but later read directly from the Node instead. I'm just committing at this stage to make subsequent diffs easier to understand.
2022-02-20 15:51:24 +01:00
*
* SPDX-License-Identifier: BSD-2-Clause
*/
LibWeb: Put debug spam about negative content sizes behind a flag We already clamp these values to zero, so it's actually pretty harmless when this happens. If someone wants to investigate these issues deeper and see if they can be fixed earlier in the layout pipeline, they can enable the spam locally.
2023-05-31 11:47:26 +02:00
#include <AK/Debug.h>
LibWeb: Detach paintables from *all* DOM nodes before committing layout Before this change, we were not detaching paintables from DOM nodes within shadow subtrees. This appears to be the main reason that keyboard editing was doing immediate forced relayout: doing a full layout invalidation meant we'd build a new layout tree, which then hid the problem with with still-attached paintables. By detaching them before committing a new layout, we make it possible for keyboard editing to just use normal relayout, instead of full forced invalidation & relayout.
2024-03-17 19:11:50 +01:00
#include <LibWeb/DOM/ShadowRoot.h>
LibWeb: Reorganize layout algorithms around available space This is a big and messy change, and here's the gist: - AvaliableSpace is now 2x AvailableSize (width and height) - Layout algorithms are redesigned around the idea of available space - When doing layout across nested formatting contexts, the parent context tells the child context how much space is available for the child's root box in both axes. - "Available space" replaces "containing block width" in most places. - The width and height in a box's UsedValues are considered to be definite after they're assigned to. Marking something as having definite size is no longer a separate step, This probably introduces various regressions, but the big win here is that our layout system now works with available space, just like the specs are written. Fixing issues will be much easier going forward, since you don't need to do nearly as much conversion from "spec logic" to "LibWeb logic" as you previously did.
2022-09-27 15:29:17 +02:00
#include <LibWeb/Layout/AvailableSpace.h>
LibWeb: Make inline paintables own their fragments The paintable tree structure more closely matches the painting order when fragments are owned by corresponding inline paintables. This change does not affect the layout tree, as it is more convenient for layout purposes to have all fragments owned by a block container in one place. Additionally, this improves performance significantly on pages with many fragments, as we no longer have to walk the ancestor chain up to the closest block container to determine if a fragment belongs to an inline paintable.
2024-01-13 13:11:31 +01:00
#include <LibWeb/Layout/InlineNode.h>
LibWeb: Rename FormattingState to LayoutState This seems a bit more descriptive (and also a bit shorter).
2022-07-16 23:30:32 +02:00
#include <LibWeb/Layout/LayoutState.h>
LibWeb: Bring measuring of scrollable overflow closer to spec Importantly, we now only consider overflow from descendants with explicltly visible overflow, and only from descendants that have the measured box as their containing block. Also, we now measure scrollable overflow for all boxes, not just scroll containers. This will allow us to fix a long-standing paint problem in the next commit.
2023-07-12 18:55:23 +02:00
#include <LibWeb/Layout/Viewport.h>
LibWeb: Support transforms, stroking, gradients, etc for SVG <text> This makes use of the new Gfx::Path::text() to handle SVG text elements, with this text is just a regular path, and can be manipulated like any other graphics element. This removes the SVGTextPaintable and makes both <text> and geometry elements use a new (shared) SVGPathPaintable. This is identical to the old SVGGeometryPaintable. This simplifies painting as once something is resolved to a Gfx::Path, the painting logic is the same.
2023-11-04 21:31:35 +00:00
#include <LibWeb/Painting/SVGPathPaintable.h>
LibWeb: Make use of transform-box when calculating transforms We don't currently calculate the fill- or stroke-boxes of SVG elements, so for now we use the content- and border-boxes respectively, as those are the closest equivalents. The test will need updating when we do support them. Also, the test is a screenshot because of rendering differences when applying transforms: a 20px box does not get painted the same as a 10px box scaled up 2x. Otherwise that would be the more ideal form of test.
2024-01-26 15:56:25 +00:00
#include <LibWeb/Painting/SVGSVGPaintable.h>
LibWeb: Resolve `text-decoration-thickness` during layout commit Refactoring towards stop resolving CSS lengths during paintable commands recording.
2024-01-25 19:21:56 +01:00
#include <LibWeb/Painting/TextPaintable.h>
LibWeb: Start making our layout system "transactional" This patch adds a map of Layout::Node to FormattingState::NodeState. Instead of updating layout nodes incrementally as layout progresses through the formatting contexts, all updates are now written to the corresponding NodeState instead. At the end of layout, FormattingState::commit() is called, which transfers all the values from the NodeState objects to the Node. This will soon allow us to perform completely non-destructive layouts which don't affect the tree. Note that there are many imperfections here, and still many places where we assign to the NodeState, but later read directly from the Node instead. I'm just committing at this stage to make subsequent diffs easier to understand.
2022-02-20 15:51:24 +01:00
namespace Web::Layout {
LibWeb: Make LayoutState use HashMap instead of potentially huge Vector 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.
2023-05-23 07:47:37 +02:00
LayoutState::~LayoutState()
{
}
LibWeb: Relax restrictions on LayoutState::get() input type Instead of only letting NodeWithStyleAndBoxModelMetrics (and subclasses) have used values in the layout state, we now allow any NodeWithStyle.
2023-09-04 12:24:48 +02:00
LayoutState::UsedValues& LayoutState::get_mutable(NodeWithStyle const& node)
LibWeb: Use copy-on-write to make cloning a FormattingState much cheaper Instead of making a full copy of every NodeState when cloning a FormattingState, we make NodeState ref-counted and implement a basic copy-on-write mechanism. FormattingState::get_mutable() now makes a deep copy of the NodeState when first accessed *if* it is shared with other FormattingStates.
2022-02-28 12:32:23 +01:00
{
LibWeb: Fix some GCVerifier warnings
2024-04-05 13:47:48 -07:00
if (auto* used_values = used_values_per_layout_node.get(node).value_or(nullptr))
LibWeb: Make LayoutState use HashMap instead of potentially huge Vector 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.
2023-05-23 07:47:37 +02:00
return *used_values;
LibWeb: Stop putting the FormattingState nodes in a slow hash map Instead, put them in a Vector<OwnPtr<NodeState>>. Each layout node has a unique index into the vector. It's a simple serial ID assigned during layout tree construction. Every new layout restarts the sequence at 0 for the next ICB. This is a huge layout speed improvement on all content.
2022-07-11 17:12:58 +02:00
LibWeb: Relax restrictions on LayoutState::get() input type Instead of only letting NodeWithStyleAndBoxModelMetrics (and subclasses) have used values in the layout state, we now allow any NodeWithStyle.
2023-09-04 12:24:48 +02:00
auto const* containing_block_used_values = node.is_viewport() ? nullptr : &get(*node.containing_block());
LibWeb: Move "has-definite-width/height" flags to UsedValues This state is less static than we originally assumed, and there are special formatting context-specific rules that say certain sizes are definite in special circumstances. To be able to support this, we move the has-definite-size flags from the layout node to the UsedValues struct instead.
2022-07-17 18:46:38 +02:00
LibWeb: Make LayoutState use HashMap instead of potentially huge Vector 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.
2023-05-23 07:47:37 +02:00
auto new_used_values = adopt_own(*new UsedValues);
auto* new_used_values_ptr = new_used_values.ptr();
LibWeb: Make node argument to UsedValues::set_node() const No functional changes.
2025-08-27 12:37:26 +02:00
new_used_values->set_node(node, containing_block_used_values);
LibWeb: Fix some GCVerifier warnings
2024-04-05 13:47:48 -07:00
used_values_per_layout_node.set(node, move(new_used_values));
LibWeb: Make LayoutState use HashMap instead of potentially huge Vector 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.
2023-05-23 07:47:37 +02:00
return *new_used_values_ptr;
LibWeb: Use copy-on-write to make cloning a FormattingState much cheaper Instead of making a full copy of every NodeState when cloning a FormattingState, we make NodeState ref-counted and implement a basic copy-on-write mechanism. FormattingState::get_mutable() now makes a deep copy of the NodeState when first accessed *if* it is shared with other FormattingStates.
2022-02-28 12:32:23 +01:00
}
LibWeb: Relax restrictions on LayoutState::get() input type Instead of only letting NodeWithStyleAndBoxModelMetrics (and subclasses) have used values in the layout state, we now allow any NodeWithStyle.
2023-09-04 12:24:48 +02:00
LayoutState::UsedValues const& LayoutState::get(NodeWithStyle const& node) const
LibWeb: Use copy-on-write to make cloning a FormattingState much cheaper Instead of making a full copy of every NodeState when cloning a FormattingState, we make NodeState ref-counted and implement a basic copy-on-write mechanism. FormattingState::get_mutable() now makes a deep copy of the NodeState when first accessed *if* it is shared with other FormattingStates.
2022-02-28 12:32:23 +01:00
{
LibWeb: Fix some GCVerifier warnings
2024-04-05 13:47:48 -07:00
if (auto const* used_values = used_values_per_layout_node.get(node).value_or(nullptr))
LibWeb: Make LayoutState use HashMap instead of potentially huge Vector 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.
2023-05-23 07:47:37 +02:00
return *used_values;
LibWeb: Stop putting the FormattingState nodes in a slow hash map Instead, put them in a Vector<OwnPtr<NodeState>>. Each layout node has a unique index into the vector. It's a simple serial ID assigned during layout tree construction. Every new layout restarts the sequence at 0 for the next ICB. This is a huge layout speed improvement on all content.
2022-07-11 17:12:58 +02:00
LibWeb: Relax restrictions on LayoutState::get() input type Instead of only letting NodeWithStyleAndBoxModelMetrics (and subclasses) have used values in the layout state, we now allow any NodeWithStyle.
2023-09-04 12:24:48 +02:00
auto const* containing_block_used_values = node.is_viewport() ? nullptr : &get(*node.containing_block());
LibWeb: Move "has-definite-width/height" flags to UsedValues This state is less static than we originally assumed, and there are special formatting context-specific rules that say certain sizes are definite in special circumstances. To be able to support this, we move the has-definite-size flags from the layout node to the UsedValues struct instead.
2022-07-17 18:46:38 +02:00
LibWeb: Make LayoutState use HashMap instead of potentially huge Vector 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.
2023-05-23 07:47:37 +02:00
auto new_used_values = adopt_own(*new UsedValues);
auto* new_used_values_ptr = new_used_values.ptr();
LibWeb: Make node argument to UsedValues::set_node() const No functional changes.
2025-08-27 12:37:26 +02:00
new_used_values->set_node(node, containing_block_used_values);
LibWeb: Fix some GCVerifier warnings
2024-04-05 13:47:48 -07:00
const_cast<LayoutState*>(this)->used_values_per_layout_node.set(node, move(new_used_values));
LibWeb: Make LayoutState use HashMap instead of potentially huge Vector 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.
2023-05-23 07:47:37 +02:00
return *new_used_values_ptr;
LibWeb: Use copy-on-write to make cloning a FormattingState much cheaper Instead of making a full copy of every NodeState when cloning a FormattingState, we make NodeState ref-counted and implement a basic copy-on-write mechanism. FormattingState::get_mutable() now makes a deep copy of the NodeState when first accessed *if* it is shared with other FormattingStates.
2022-02-28 12:32:23 +01:00
}
LibWeb: Implement the unreachable scrollable overflow Whenever we end up with a scrollable overflow rect that goes beyond either of its axes (i.e. the rect has a negative X or Y position relative to its parent's absolute padding box position), we need to clip that rect to prevent going into the "unreachable scrollable overflow". This fixes the horizontal scrolling on https://ladybird.org (gets more pronounced if you make the window very narrow).
2025-07-10 11:43:46 +02:00
// https://drafts.csswg.org/css-overflow-3/#scrollable-overflow-region
LibWeb: Bring measuring of scrollable overflow closer to spec Importantly, we now only consider overflow from descendants with explicltly visible overflow, and only from descendants that have the measured box as their containing block. Also, we now measure scrollable overflow for all boxes, not just scroll containers. This will allow us to fix a long-standing paint problem in the next commit.
2023-07-12 18:55:23 +02:00
static CSSPixelRect measure_scrollable_overflow(Box const& box)
LibWeb: Measure the overflow for all scroll containers Instead of just measuring the layout viewport, we now measure overflow in every box that is a scroll container. This has the side effect of no longer creating paintables for layout boxes that didn't participate in layout. (For example, empty/anonymous boxes that were ignored by flex itemization.) Such boxes are now marked as "(not painted)" in the layout tree dumps, as they have no paintable to dump geometry from.
2023-05-29 08:53:39 +02:00
{
LibWeb: Bring measuring of scrollable overflow closer to spec Importantly, we now only consider overflow from descendants with explicltly visible overflow, and only from descendants that have the measured box as their containing block. Also, we now measure scrollable overflow for all boxes, not just scroll containers. This will allow us to fix a long-standing paint problem in the next commit.
2023-07-12 18:55:23 +02:00
if (!box.paintable_box())
return {};
LibWeb: Let PaintableBox be const for longer in LayoutState Makes it clearer where we're modifying it. No functional changes.
2025-08-29 10:30:55 +02:00
auto const& paintable_box = *box.paintable_box();
LibWeb: Bring measuring of scrollable overflow closer to spec Importantly, we now only consider overflow from descendants with explicltly visible overflow, and only from descendants that have the measured box as their containing block. Also, we now measure scrollable overflow for all boxes, not just scroll containers. This will allow us to fix a long-standing paint problem in the next commit.
2023-07-12 18:55:23 +02:00
if (paintable_box.scrollable_overflow_rect().has_value())
return paintable_box.scrollable_overflow_rect().value();
// The scrollable overflow area is the union of:
// - The scroll container’s own padding box.
LibWeb: Implement the unreachable scrollable overflow Whenever we end up with a scrollable overflow rect that goes beyond either of its axes (i.e. the rect has a negative X or Y position relative to its parent's absolute padding box position), we need to clip that rect to prevent going into the "unreachable scrollable overflow". This fixes the horizontal scrolling on https://ladybird.org (gets more pronounced if you make the window very narrow).
2025-07-10 11:43:46 +02:00
auto const paintable_absolute_padding_box = paintable_box.absolute_padding_box_rect();
auto scrollable_overflow_rect = paintable_absolute_padding_box;
LibWeb: Bring measuring of scrollable overflow closer to spec Importantly, we now only consider overflow from descendants with explicltly visible overflow, and only from descendants that have the measured box as their containing block. Also, we now measure scrollable overflow for all boxes, not just scroll containers. This will allow us to fix a long-standing paint problem in the next commit.
2023-07-12 18:55:23 +02:00
// - All line boxes directly contained by the scroll container.
LibWeb: Misc. code cleanup of LayoutState No functional changes.
2025-08-29 11:00:35 +02:00
if (auto const* paintable_with_lines = as_if<Painting::PaintableWithLines>(box.first_paintable())) {
for (auto const& fragment : paintable_with_lines->fragments())
LibGfx: Add `Rect::unite()` The existing `::unite_horizontally()` and `::unite_vertically()` tests did not properly test the edge cases where left/top in the Rect were updated, so they get re-arranged a bit.
2025-01-15 13:51:39 +01:00
scrollable_overflow_rect.unite(fragment.absolute_rect());
LibWeb: Bring measuring of scrollable overflow closer to spec Importantly, we now only consider overflow from descendants with explicltly visible overflow, and only from descendants that have the measured box as their containing block. Also, we now measure scrollable overflow for all boxes, not just scroll containers. This will allow us to fix a long-standing paint problem in the next commit.
2023-07-12 18:55:23 +02:00
}
LibWeb: Add additional padding to the end of the scrollable overflow Adds additional padding to the end-side of the scrollable overflow rectangle as necessary to enable a scroll position that satisfies the requirements of `place-content: end` alignment.
2024-08-01 14:29:09 +01:00
auto content_overflow_rect = scrollable_overflow_rect;
LibWeb: Implement the unreachable scrollable overflow Whenever we end up with a scrollable overflow rect that goes beyond either of its axes (i.e. the rect has a negative X or Y position relative to its parent's absolute padding box position), we need to clip that rect to prevent going into the "unreachable scrollable overflow". This fixes the horizontal scrolling on https://ladybird.org (gets more pronounced if you make the window very narrow).
2025-07-10 11:43:46 +02:00
// - The border boxes of all boxes for which it is the containing block and whose border boxes are positioned not
// wholly in the negative scrollable overflow region,
LibWeb: Bring measuring of scrollable overflow closer to spec Importantly, we now only consider overflow from descendants with explicltly visible overflow, and only from descendants that have the measured box as their containing block. Also, we now measure scrollable overflow for all boxes, not just scroll containers. This will allow us to fix a long-standing paint problem in the next commit.
2023-07-12 18:55:23 +02:00
// FIXME: accounting for transforms by projecting each box onto the plane of the element that establishes its 3D rendering context. [CSS3-TRANSFORMS]
LibWeb: Allow descendant boxes to contribute in overflow rect of parent ...with inline children. This fixes an issue when we ignore abspos boxes contained by PaintableWithLines while calculating overflow rect size. Lots of layout tests are affected, because now PaintableWithLines has overflow rect. `Text/input/DOM/Element-set-scroll-left.html` is also affected and now matches other browsers.
2025-07-05 17:05:55 +02:00
box.for_each_in_subtree_of_type<Box>([&box, &scrollable_overflow_rect, &content_overflow_rect](Box const& child) {
if (!child.paintable_box())
return TraversalDecision::Continue;
LibWeb: Bring measuring of scrollable overflow closer to spec Importantly, we now only consider overflow from descendants with explicltly visible overflow, and only from descendants that have the measured box as their containing block. Also, we now measure scrollable overflow for all boxes, not just scroll containers. This will allow us to fix a long-standing paint problem in the next commit.
2023-07-12 18:55:23 +02:00
LibWeb: Allow descendant boxes to contribute in overflow rect of parent ...with inline children. This fixes an issue when we ignore abspos boxes contained by PaintableWithLines while calculating overflow rect size. Lots of layout tests are affected, because now PaintableWithLines has overflow rect. `Text/input/DOM/Element-set-scroll-left.html` is also affected and now matches other browsers.
2025-07-05 17:05:55 +02:00
if (child.containing_block() != &box)
LibWeb: Use containing block to compute scrollable overflow Instead of using child boxes to compute scrollable overflow for the box, we use descendants which have the box as their containing block.
2024-10-15 10:35:11 -04:00
return TraversalDecision::Continue;
LibWeb: Allow descendant boxes to contribute in overflow rect of parent ...with inline children. This fixes an issue when we ignore abspos boxes contained by PaintableWithLines while calculating overflow rect size. Lots of layout tests are affected, because now PaintableWithLines has overflow rect. `Text/input/DOM/Element-set-scroll-left.html` is also affected and now matches other browsers.
2025-07-05 17:05:55 +02:00
// https://drafts.csswg.org/css-position/#fixed-positioning-containing-block
// [..] As a result, parts of fixed-positioned boxes that extend outside the layout viewport/page area
// cannot be scrolled to and will not print.
// FIXME: Properly establish the fixed positioning containing block for `position: fixed`
if (child.is_fixed_position())
return TraversalDecision::Continue;
auto child_border_box = child.paintable_box()->absolute_border_box_rect();
// Border boxes with zero area do not affect the scrollable overflow area.
if (child_border_box.is_empty())
return TraversalDecision::Continue;
// NOTE: Here we check that the child is not wholly in the negative scrollable overflow region.
if (child_border_box.bottom() < 0 || child_border_box.right() < 0)
return TraversalDecision::Continue;
scrollable_overflow_rect.unite(child_border_box);
content_overflow_rect.unite(child_border_box);
LibWeb: Implement the unreachable scrollable overflow Whenever we end up with a scrollable overflow rect that goes beyond either of its axes (i.e. the rect has a negative X or Y position relative to its parent's absolute padding box position), we need to clip that rect to prevent going into the "unreachable scrollable overflow". This fixes the horizontal scrolling on https://ladybird.org (gets more pronounced if you make the window very narrow).
2025-07-10 11:43:46 +02:00
// - The scrollable overflow areas of all of the above boxes (including zero-area boxes and accounting for
// transforms as described above), provided they themselves have overflow: visible (i.e. do not themselves
// trap the overflow) and that scrollable overflow is not already clipped (e.g. by the clip property or the
// contain property).
LibWeb: Allow descendant boxes to contribute in overflow rect of parent ...with inline children. This fixes an issue when we ignore abspos boxes contained by PaintableWithLines while calculating overflow rect size. Lots of layout tests are affected, because now PaintableWithLines has overflow rect. `Text/input/DOM/Element-set-scroll-left.html` is also affected and now matches other browsers.
2025-07-05 17:05:55 +02:00
if (child.computed_values().overflow_x() == CSS::Overflow::Visible || child.computed_values().overflow_y() == CSS::Overflow::Visible) {
auto child_scrollable_overflow = measure_scrollable_overflow(child);
if (child.computed_values().overflow_x() == CSS::Overflow::Visible)
scrollable_overflow_rect.unite_horizontally(child_scrollable_overflow);
if (child.computed_values().overflow_y() == CSS::Overflow::Visible)
scrollable_overflow_rect.unite_vertically(child_scrollable_overflow);
}
return TraversalDecision::Continue;
});
LibWeb: Bring measuring of scrollable overflow closer to spec Importantly, we now only consider overflow from descendants with explicltly visible overflow, and only from descendants that have the measured box as their containing block. Also, we now measure scrollable overflow for all boxes, not just scroll containers. This will allow us to fix a long-standing paint problem in the next commit.
2023-07-12 18:55:23 +02:00
// FIXME: - The margin areas of grid item and flex item boxes for which the box establishes a containing block.
LibWeb: Implement the unreachable scrollable overflow Whenever we end up with a scrollable overflow rect that goes beyond either of its axes (i.e. the rect has a negative X or Y position relative to its parent's absolute padding box position), we need to clip that rect to prevent going into the "unreachable scrollable overflow". This fixes the horizontal scrolling on https://ladybird.org (gets more pronounced if you make the window very narrow).
2025-07-10 11:43:46 +02:00
// - Additional padding added to the scrollable overflow rectangle as necessary to enable scroll positions that
// satisfy the requirements of both place-content: start and place-content: end alignment.
auto has_scrollable_overflow = !paintable_absolute_padding_box.contains(scrollable_overflow_rect);
LibWeb: Add additional padding to the end of the scrollable overflow Adds additional padding to the end-side of the scrollable overflow rectangle as necessary to enable a scroll position that satisfies the requirements of `place-content: end` alignment.
2024-08-01 14:29:09 +01:00
if (has_scrollable_overflow) {
LibWeb: Store final box model metrics in paint tree, not layout tree This was a weird case of layout results being stored in the layout tree instead of in the paint tree like everything else.
2025-02-17 13:54:36 +01:00
scrollable_overflow_rect.set_height(max(scrollable_overflow_rect.height(), content_overflow_rect.height() + paintable_box.box_model().padding.bottom));
LibWeb: Add additional padding to the end of the scrollable overflow Adds additional padding to the end-side of the scrollable overflow rectangle as necessary to enable a scroll position that satisfies the requirements of `place-content: end` alignment.
2024-08-01 14:29:09 +01:00
}
LibWeb: Bring measuring of scrollable overflow closer to spec Importantly, we now only consider overflow from descendants with explicltly visible overflow, and only from descendants that have the measured box as their containing block. Also, we now measure scrollable overflow for all boxes, not just scroll containers. This will allow us to fix a long-standing paint problem in the next commit.
2023-07-12 18:55:23 +02:00
LibWeb: Implement the unreachable scrollable overflow Whenever we end up with a scrollable overflow rect that goes beyond either of its axes (i.e. the rect has a negative X or Y position relative to its parent's absolute padding box position), we need to clip that rect to prevent going into the "unreachable scrollable overflow". This fixes the horizontal scrolling on https://ladybird.org (gets more pronounced if you make the window very narrow).
2025-07-10 11:43:46 +02:00
// Additionally, due to Web-compatibility constraints (caused by authors exploiting legacy bugs to surreptitiously
// hide content from visual readers but not search engines and/or speech output), UAs must clip any content in the
// unreachable scrollable overflow region.
//
// https://drafts.csswg.org/css-overflow-3/#unreachable-scrollable-overflow-region
// Unless otherwise adjusted (e.g. by content alignment [css-align-3]), the area beyond the scroll origin in either
// axis is considered the unreachable scrollable overflow region: content rendered here is not accessible to the
// reader, see § 2.2 Scrollable Overflow.
// FIXME: The scroll origin and overflow directions are determined by ( block-start, inline-start ) or ( main-start,
// cross-start) for flex containers. Currently we assume the top-left of the absolute padding box.
if (scrollable_overflow_rect.x() < paintable_absolute_padding_box.x() || scrollable_overflow_rect.y() < paintable_absolute_padding_box.y()) {
scrollable_overflow_rect.set_size({
max(scrollable_overflow_rect.width() + min(scrollable_overflow_rect.x() - paintable_absolute_padding_box.x(), 0), 0),
max(scrollable_overflow_rect.height() + min(scrollable_overflow_rect.y() - paintable_absolute_padding_box.y(), 0), 0),
});
scrollable_overflow_rect.set_location({
max(scrollable_overflow_rect.x(), paintable_absolute_padding_box.x()),
max(scrollable_overflow_rect.y(), paintable_absolute_padding_box.y()),
});
has_scrollable_overflow = !paintable_absolute_padding_box.contains(scrollable_overflow_rect);
}
LibWeb: Let PaintableBox be const for longer in LayoutState Makes it clearer where we're modifying it. No functional changes.
2025-08-29 10:30:55 +02:00
const_cast<Painting::PaintableBox&>(paintable_box).set_overflow_data({
LibWeb: Bring measuring of scrollable overflow closer to spec Importantly, we now only consider overflow from descendants with explicltly visible overflow, and only from descendants that have the measured box as their containing block. Also, we now measure scrollable overflow for all boxes, not just scroll containers. This will allow us to fix a long-standing paint problem in the next commit.
2023-07-12 18:55:23 +02:00
.scrollable_overflow_rect = scrollable_overflow_rect,
LibWeb: Add additional padding to the end of the scrollable overflow Adds additional padding to the end-side of the scrollable overflow rectangle as necessary to enable a scroll position that satisfies the requirements of `place-content: end` alignment.
2024-08-01 14:29:09 +01:00
.has_scrollable_overflow = has_scrollable_overflow,
LibWeb: Bring measuring of scrollable overflow closer to spec Importantly, we now only consider overflow from descendants with explicltly visible overflow, and only from descendants that have the measured box as their containing block. Also, we now measure scrollable overflow for all boxes, not just scroll containers. This will allow us to fix a long-standing paint problem in the next commit.
2023-07-12 18:55:23 +02:00
});
return scrollable_overflow_rect;
LibWeb: Measure the overflow for all scroll containers Instead of just measuring the layout viewport, we now measure overflow in every box that is a scroll container. This has the side effect of no longer creating paintables for layout boxes that didn't participate in layout. (For example, empty/anonymous boxes that were ignored by flex itemization.) Such boxes are now marked as "(not painted)" in the layout tree dumps, as they have no paintable to dump geometry from.
2023-05-29 08:53:39 +02:00
}
LibWeb: Resolve relpos fragment offsets only for inline paintables Prior to this change, we iterated through all fragments within each PaintableWithLines to resolve the relative position offset. This happened before transferring the fragments to their corresponding inline paintables. With this change, we significantly reduce amount of work by attempting to resolve relative position offsets only for those contained within inline paintables. Performance improvement on https://html.spec.whatwg.org/
2024-01-18 14:03:30 +01:00
void LayoutState::resolve_relative_positions()
LibWeb: Resolve relative offsets *once* after layout Instead of applying relative offsets (like position:relative insets) during painting and hit testing, we now do a pass at the end of layout and assign the final resolved offsets to paintables. This makes painting and hit testing easier since they don't have to think about relative offsets, and it also fixes a bug where offsets were not applied to text fragments inside inline-flow elements that were themselves position:relative.
2023-08-15 15:11:10 +02:00
{
LibWeb: Resolve relpos fragment offsets only for inline paintables Prior to this change, we iterated through all fragments within each PaintableWithLines to resolve the relative position offset. This happened before transferring the fragments to their corresponding inline paintables. With this change, we significantly reduce amount of work by attempting to resolve relative position offsets only for those contained within inline paintables. Performance improvement on https://html.spec.whatwg.org/
2024-01-18 14:03:30 +01:00
// This function resolves relative position offsets of fragments that belong to inline paintables.
LibWeb: Resolve relative offsets *once* after layout Instead of applying relative offsets (like position:relative insets) during painting and hit testing, we now do a pass at the end of layout and assign the final resolved offsets to paintables. This makes painting and hit testing easier since they don't have to think about relative offsets, and it also fixes a bug where offsets were not applied to text fragments inside inline-flow elements that were themselves position:relative.
2023-08-15 15:11:10 +02:00
// It runs *after* the paint tree has been constructed, so it modifies paintable node & fragment offsets directly.
for (auto& it : used_values_per_layout_node) {
auto& used_values = *it.value;
LibWeb: Relax restrictions on LayoutState::get() input type Instead of only letting NodeWithStyleAndBoxModelMetrics (and subclasses) have used values in the layout state, we now allow any NodeWithStyle.
2023-09-04 12:24:48 +02:00
auto& node = const_cast<NodeWithStyle&>(used_values.node());
LibWeb: Resolve relative offsets *once* after layout Instead of applying relative offsets (like position:relative insets) during painting and hit testing, we now do a pass at the end of layout and assign the final resolved offsets to paintables. This makes painting and hit testing easier since they don't have to think about relative offsets, and it also fixes a bug where offsets were not applied to text fragments inside inline-flow elements that were themselves position:relative.
2023-08-15 15:11:10 +02:00
LibWeb: Replace InlinePaintable with PaintableWithLines created per line InlinePaintable was an ad-hoc paintable type required to support the fragmentation of inline nodes across multiple lines. It existed because there was no way to associate multiple paintables with a single layout node. This resulted in a lot of duplicated code between PaintableBox and InlinePaintable. For example, most of the CSS properties like background, border, shadows, etc. and hit-testing are almost identical for both of them. However, the code had to be duplicated to account for the fact that InlinePaintable creates a box for each line. And we had quite many places that operate on paintables with a code like: ``` if (box.is_paintable_box()) { // do something } else (box.is_inline_paintable()) { // do exactly the same as for paintable box but using InlinePaintable } ``` This change replaces the usage of `InlinePaintable` with `PaintableWithLines` created for each line, which is now possible because we support having multiple paintables per layout node. By doing that, we remove lots of duplicated code and bring our implementation closer to the spec.
2024-10-13 21:29:47 +02:00
for (auto& paintable : node.paintables()) {
if (!(is<Painting::PaintableWithLines>(paintable) && is<Layout::InlineNode>(paintable.layout_node())))
LibWeb: Use separate structure to represent fragments in paintable tree This is a part of refactoring towards making the paintable tree independent of the layout tree. Now, instead of transferring text fragments from the layout tree to the paintable tree during the layout commit phase, we allocate separate PaintableFragments that contain only the information necessary for painting. Doing this also allows us to get rid LineBoxes, as they are used only during layout.
2024-01-12 21:25:05 +01:00
continue;
LibWeb: Replace InlinePaintable with PaintableWithLines created per line InlinePaintable was an ad-hoc paintable type required to support the fragmentation of inline nodes across multiple lines. It existed because there was no way to associate multiple paintables with a single layout node. This resulted in a lot of duplicated code between PaintableBox and InlinePaintable. For example, most of the CSS properties like background, border, shadows, etc. and hit-testing are almost identical for both of them. However, the code had to be duplicated to account for the fact that InlinePaintable creates a box for each line. And we had quite many places that operate on paintables with a code like: ``` if (box.is_paintable_box()) { // do something } else (box.is_inline_paintable()) { // do exactly the same as for paintable box but using InlinePaintable } ``` This change replaces the usage of `InlinePaintable` with `PaintableWithLines` created for each line, which is now possible because we support having multiple paintables per layout node. By doing that, we remove lots of duplicated code and bring our implementation closer to the spec.
2024-10-13 21:29:47 +02:00
auto const& inline_paintable = static_cast<Painting::PaintableWithLines&>(paintable);
for (auto& fragment : inline_paintable.fragments()) {
auto const& fragment_node = fragment.layout_node();
if (!is<Layout::NodeWithStyleAndBoxModelMetrics>(*fragment_node.parent()))
continue;
// Collect effective relative position offset from inline-flow parent chain.
CSSPixelPoint offset;
for (auto* ancestor = fragment_node.parent(); ancestor; ancestor = ancestor->parent()) {
if (!is<Layout::NodeWithStyleAndBoxModelMetrics>(*ancestor))
break;
if (!ancestor->display().is_inline_outside() || !ancestor->display().is_flow_inside())
break;
if (ancestor->computed_values().position() == CSS::Positioning::Relative) {
LibWeb: Store final box model metrics in paint tree, not layout tree This was a weird case of layout results being stored in the layout tree instead of in the paint tree like everything else.
2025-02-17 13:54:36 +01:00
VERIFY(ancestor->first_paintable());
auto const& ancestor_node = as<Painting::PaintableBox>(*ancestor->first_paintable());
LibWeb: Replace InlinePaintable with PaintableWithLines created per line InlinePaintable was an ad-hoc paintable type required to support the fragmentation of inline nodes across multiple lines. It existed because there was no way to associate multiple paintables with a single layout node. This resulted in a lot of duplicated code between PaintableBox and InlinePaintable. For example, most of the CSS properties like background, border, shadows, etc. and hit-testing are almost identical for both of them. However, the code had to be duplicated to account for the fact that InlinePaintable creates a box for each line. And we had quite many places that operate on paintables with a code like: ``` if (box.is_paintable_box()) { // do something } else (box.is_inline_paintable()) { // do exactly the same as for paintable box but using InlinePaintable } ``` This change replaces the usage of `InlinePaintable` with `PaintableWithLines` created for each line, which is now possible because we support having multiple paintables per layout node. By doing that, we remove lots of duplicated code and bring our implementation closer to the spec.
2024-10-13 21:29:47 +02:00
auto const& inset = ancestor_node.box_model().inset;
offset.translate_by(inset.left, inset.top);
}
LibWeb: Resolve relative offsets *once* after layout Instead of applying relative offsets (like position:relative insets) during painting and hit testing, we now do a pass at the end of layout and assign the final resolved offsets to paintables. This makes painting and hit testing easier since they don't have to think about relative offsets, and it also fixes a bug where offsets were not applied to text fragments inside inline-flow elements that were themselves position:relative.
2023-08-15 15:11:10 +02:00
}
LibWeb: Replace InlinePaintable with PaintableWithLines created per line InlinePaintable was an ad-hoc paintable type required to support the fragmentation of inline nodes across multiple lines. It existed because there was no way to associate multiple paintables with a single layout node. This resulted in a lot of duplicated code between PaintableBox and InlinePaintable. For example, most of the CSS properties like background, border, shadows, etc. and hit-testing are almost identical for both of them. However, the code had to be duplicated to account for the fact that InlinePaintable creates a box for each line. And we had quite many places that operate on paintables with a code like: ``` if (box.is_paintable_box()) { // do something } else (box.is_inline_paintable()) { // do exactly the same as for paintable box but using InlinePaintable } ``` This change replaces the usage of `InlinePaintable` with `PaintableWithLines` created for each line, which is now possible because we support having multiple paintables per layout node. By doing that, we remove lots of duplicated code and bring our implementation closer to the spec.
2024-10-13 21:29:47 +02:00
const_cast<Painting::PaintableFragment&>(fragment).set_offset(fragment.offset().translated(offset));
LibWeb: Resolve relative offsets *once* after layout Instead of applying relative offsets (like position:relative insets) during painting and hit testing, we now do a pass at the end of layout and assign the final resolved offsets to paintables. This makes painting and hit testing easier since they don't have to think about relative offsets, and it also fixes a bug where offsets were not applied to text fragments inside inline-flow elements that were themselves position:relative.
2023-08-15 15:11:10 +02:00
}
}
}
}
LibWeb: Make the paint tree a proper standalone tree Until now, paint trees have been piggybacking on the layout tree for traversal, and paintables didn't actually have their own parent/child pointers. This patch changes that by making Paintable inherit from TreeNode, and adding a new pass to LayoutState::commit() where we recursively build the new paint tree.
2023-08-18 12:30:27 +02:00
static void build_paint_tree(Node& node, Painting::Paintable* parent_paintable = nullptr)
{
LibWeb: Replace InlinePaintable with PaintableWithLines created per line InlinePaintable was an ad-hoc paintable type required to support the fragmentation of inline nodes across multiple lines. It existed because there was no way to associate multiple paintables with a single layout node. This resulted in a lot of duplicated code between PaintableBox and InlinePaintable. For example, most of the CSS properties like background, border, shadows, etc. and hit-testing are almost identical for both of them. However, the code had to be duplicated to account for the fact that InlinePaintable creates a box for each line. And we had quite many places that operate on paintables with a code like: ``` if (box.is_paintable_box()) { // do something } else (box.is_inline_paintable()) { // do exactly the same as for paintable box but using InlinePaintable } ``` This change replaces the usage of `InlinePaintable` with `PaintableWithLines` created for each line, which is now possible because we support having multiple paintables per layout node. By doing that, we remove lots of duplicated code and bring our implementation closer to the spec.
2024-10-13 21:29:47 +02:00
for (auto& paintable : node.paintables()) {
if (parent_paintable && !paintable.forms_unconnected_subtree()) {
VERIFY(!paintable.parent());
parent_paintable->append_child(paintable);
LibWeb: Create paintables for nodes whose parents don't have paintables A Paintable is not created for an SVG <defs> element (nor should it), but it can contain SVG <mask> elements that need a paintable. This change forces those paintables to be created (without a parent). The masks are then only painted by being referenced from another element.
2023-09-10 14:03:13 +01:00
}
LibWeb: Replace InlinePaintable with PaintableWithLines created per line InlinePaintable was an ad-hoc paintable type required to support the fragmentation of inline nodes across multiple lines. It existed because there was no way to associate multiple paintables with a single layout node. This resulted in a lot of duplicated code between PaintableBox and InlinePaintable. For example, most of the CSS properties like background, border, shadows, etc. and hit-testing are almost identical for both of them. However, the code had to be duplicated to account for the fact that InlinePaintable creates a box for each line. And we had quite many places that operate on paintables with a code like: ``` if (box.is_paintable_box()) { // do something } else (box.is_inline_paintable()) { // do exactly the same as for paintable box but using InlinePaintable } ``` This change replaces the usage of `InlinePaintable` with `PaintableWithLines` created for each line, which is now possible because we support having multiple paintables per layout node. By doing that, we remove lots of duplicated code and bring our implementation closer to the spec.
2024-10-13 21:29:47 +02:00
paintable.set_dom_node(node.dom_node());
LibWeb: Create paintables for nodes whose parents don't have paintables A Paintable is not created for an SVG <defs> element (nor should it), but it can contain SVG <mask> elements that need a paintable. This change forces those paintables to be created (without a parent). The masks are then only painted by being referenced from another element.
2023-09-10 14:03:13 +01:00
if (node.dom_node())
node.dom_node()->set_paintable(paintable);
LibWeb: Make the paint tree a proper standalone tree Until now, paint trees have been piggybacking on the layout tree for traversal, and paintables didn't actually have their own parent/child pointers. This patch changes that by making Paintable inherit from TreeNode, and adding a new pass to LayoutState::commit() where we recursively build the new paint tree.
2023-08-18 12:30:27 +02:00
}
for (auto* child = node.first_child(); child; child = child->next_sibling()) {
LibWeb: Replace InlinePaintable with PaintableWithLines created per line InlinePaintable was an ad-hoc paintable type required to support the fragmentation of inline nodes across multiple lines. It existed because there was no way to associate multiple paintables with a single layout node. This resulted in a lot of duplicated code between PaintableBox and InlinePaintable. For example, most of the CSS properties like background, border, shadows, etc. and hit-testing are almost identical for both of them. However, the code had to be duplicated to account for the fact that InlinePaintable creates a box for each line. And we had quite many places that operate on paintables with a code like: ``` if (box.is_paintable_box()) { // do something } else (box.is_inline_paintable()) { // do exactly the same as for paintable box but using InlinePaintable } ``` This change replaces the usage of `InlinePaintable` with `PaintableWithLines` created for each line, which is now possible because we support having multiple paintables per layout node. By doing that, we remove lots of duplicated code and bring our implementation closer to the spec.
2024-10-13 21:29:47 +02:00
build_paint_tree(*child, node.first_paintable());
LibWeb: Make the paint tree a proper standalone tree Until now, paint trees have been piggybacking on the layout tree for traversal, and paintables didn't actually have their own parent/child pointers. This patch changes that by making Paintable inherit from TreeNode, and adding a new pass to LayoutState::commit() where we recursively build the new paint tree.
2023-08-18 12:30:27 +02:00
}
}
void LayoutState::commit(Box& root)
LibWeb: Start making our layout system "transactional" This patch adds a map of Layout::Node to FormattingState::NodeState. Instead of updating layout nodes incrementally as layout progresses through the formatting contexts, all updates are now written to the corresponding NodeState instead. At the end of layout, FormattingState::commit() is called, which transfers all the values from the NodeState objects to the Node. This will soon allow us to perform completely non-destructive layouts which don't affect the tree. Note that there are many imperfections here, and still many places where we assign to the NodeState, but later read directly from the Node instead. I'm just committing at this stage to make subsequent diffs easier to understand.
2022-02-20 15:51:24 +01:00
{
LibWeb: Detach paint tree from layout tree in one go We used to only walk the paintable root tree from the layout root and detach paintables from there. In some cases, this could leave paintables behind, so we added another loop that iterates over all layout nodes and detaches their paintables, if any remained. Instead of traversing two trees like this, just traverse the layout tree once and detach the inclusive descendant's paintables, similar to how we deal with the DOM tree immediately after that.
2025-08-29 10:32:52 +02:00
// Go through the layout tree and detach all paintables. The layout tree should only point to the new paintable tree
// which we're about to build.
root.for_each_in_inclusive_subtree([](Node& node) {
LibWeb: Allow layout nodes to have multiple paintables CSS fragmentation implies 1:N relationship between layout nodes and paintables. This change is a preparation for implementation of inline fragmentation where InlinePaintable will be replaced with PaintableWithLines corresponding to each line.
2024-10-14 16:07:56 +02:00
node.clear_paintables();
LibWeb: Use `TraversalDecision` for multi level Node traversal methods This adds the `SkipChildrenAndContinue` option, where traversal continues but child nodes are not included.
2024-05-04 14:47:04 +01:00
return TraversalDecision::Continue;
LibWeb: Prune old paintable pointers from layout tree after relayout When text paintables shift around in the tree due to line wrapping, we may end up in a situation where some text node does not generate a paintable (due to being all whitespace, for example), even though in the previous layout pass, it *did* generate a paintable. To prevent holding on to old paintables in such cases, we now do a pass in LayoutState::commit() where we explicitly detach all old paintables from the layout tree.
2023-08-29 16:27:16 +02:00
});
LibWeb: Replace InlinePaintable with PaintableWithLines created per line InlinePaintable was an ad-hoc paintable type required to support the fragmentation of inline nodes across multiple lines. It existed because there was no way to associate multiple paintables with a single layout node. This resulted in a lot of duplicated code between PaintableBox and InlinePaintable. For example, most of the CSS properties like background, border, shadows, etc. and hit-testing are almost identical for both of them. However, the code had to be duplicated to account for the fact that InlinePaintable creates a box for each line. And we had quite many places that operate on paintables with a code like: ``` if (box.is_paintable_box()) { // do something } else (box.is_inline_paintable()) { // do exactly the same as for paintable box but using InlinePaintable } ``` This change replaces the usage of `InlinePaintable` with `PaintableWithLines` created for each line, which is now possible because we support having multiple paintables per layout node. By doing that, we remove lots of duplicated code and bring our implementation closer to the spec.
2024-10-13 21:29:47 +02:00
LibWeb: More thoroughly detach layout/paint trees from each other Before committing a new layout (and thus building a new paint tree) we now go through both the old paint tree and the layout tree and detach them from each other. This is a little extra work, but it ensures that there are no lingering references across the trees, which we were apparently accumulating in some cases on Discord, causing GC leaks.
2025-07-30 16:57:03 +02:00
// After this point, we should have a clean slate to build the new paint tree.
LibWeb: Replace InlinePaintable with PaintableWithLines created per line InlinePaintable was an ad-hoc paintable type required to support the fragmentation of inline nodes across multiple lines. It existed because there was no way to associate multiple paintables with a single layout node. This resulted in a lot of duplicated code between PaintableBox and InlinePaintable. For example, most of the CSS properties like background, border, shadows, etc. and hit-testing are almost identical for both of them. However, the code had to be duplicated to account for the fact that InlinePaintable creates a box for each line. And we had quite many places that operate on paintables with a code like: ``` if (box.is_paintable_box()) { // do something } else (box.is_inline_paintable()) { // do exactly the same as for paintable box but using InlinePaintable } ``` This change replaces the usage of `InlinePaintable` with `PaintableWithLines` created for each line, which is now possible because we support having multiple paintables per layout node. By doing that, we remove lots of duplicated code and bring our implementation closer to the spec.
2024-10-13 21:29:47 +02:00
HashTable<Layout::InlineNode*> inline_nodes;
LibWeb: Detach paintables from *all* DOM nodes before committing layout Before this change, we were not detaching paintables from DOM nodes within shadow subtrees. This appears to be the main reason that keyboard editing was doing immediate forced relayout: doing a full layout invalidation meant we'd build a new layout tree, which then hid the problem with with still-attached paintables. By detaching them before committing a new layout, we make it possible for keyboard editing to just use normal relayout, instead of full forced invalidation & relayout.
2024-03-17 19:11:50 +01:00
root.document().for_each_shadow_including_inclusive_descendant([&](DOM::Node& node) {
LibWeb: Allow layout nodes to have multiple paintables CSS fragmentation implies 1:N relationship between layout nodes and paintables. This change is a preparation for implementation of inline fragmentation where InlinePaintable will be replaced with PaintableWithLines corresponding to each line.
2024-10-14 16:07:56 +02:00
node.clear_paintable();
LibWeb: Replace InlinePaintable with PaintableWithLines created per line InlinePaintable was an ad-hoc paintable type required to support the fragmentation of inline nodes across multiple lines. It existed because there was no way to associate multiple paintables with a single layout node. This resulted in a lot of duplicated code between PaintableBox and InlinePaintable. For example, most of the CSS properties like background, border, shadows, etc. and hit-testing are almost identical for both of them. However, the code had to be duplicated to account for the fact that InlinePaintable creates a box for each line. And we had quite many places that operate on paintables with a code like: ``` if (box.is_paintable_box()) { // do something } else (box.is_inline_paintable()) { // do exactly the same as for paintable box but using InlinePaintable } ``` This change replaces the usage of `InlinePaintable` with `PaintableWithLines` created for each line, which is now possible because we support having multiple paintables per layout node. By doing that, we remove lots of duplicated code and bring our implementation closer to the spec.
2024-10-13 21:29:47 +02:00
if (node.layout_node() && is<InlineNode>(node.layout_node())) {
LibWeb: Support inserting non-inline elements into inline elements Our layout tree requires that all containers either have inline or non-inline children. In order to support the layout of non-inline elements inside inline elements, we need to do a bit of tree restructuring. It effectively simulates temporarily closing all inline nodes, appending the block element, and resumes appending to the last open inline node. The acid1.txt expectation needed to be updated to reflect the fact that we now hoist its <p> elements out of the inline <form> they were in. Visually, the before and after situations for acid1.html are identical.
2025-01-15 16:37:30 +01:00
// Inline nodes might have a continuation chain; add all inline nodes that are part of it.
for (GC::Ptr inline_node = static_cast<NodeWithStyleAndBoxModelMetrics*>(node.layout_node());
inline_node; inline_node = inline_node->continuation_of_node()) {
if (is<InlineNode>(*inline_node))
inline_nodes.set(static_cast<InlineNode*>(inline_node.ptr()));
}
LibWeb: Replace InlinePaintable with PaintableWithLines created per line InlinePaintable was an ad-hoc paintable type required to support the fragmentation of inline nodes across multiple lines. It existed because there was no way to associate multiple paintables with a single layout node. This resulted in a lot of duplicated code between PaintableBox and InlinePaintable. For example, most of the CSS properties like background, border, shadows, etc. and hit-testing are almost identical for both of them. However, the code had to be duplicated to account for the fact that InlinePaintable creates a box for each line. And we had quite many places that operate on paintables with a code like: ``` if (box.is_paintable_box()) { // do something } else (box.is_inline_paintable()) { // do exactly the same as for paintable box but using InlinePaintable } ``` This change replaces the usage of `InlinePaintable` with `PaintableWithLines` created for each line, which is now possible because we support having multiple paintables per layout node. By doing that, we remove lots of duplicated code and bring our implementation closer to the spec.
2024-10-13 21:29:47 +02:00
}
LibWeb: Use `TraversalDecision` for multi level Node traversal methods This adds the `SkipChildrenAndContinue` option, where traversal continues but child nodes are not included.
2024-05-04 14:47:04 +01:00
return TraversalDecision::Continue;
LibWeb: Detach paintables from *all* DOM nodes before committing layout Before this change, we were not detaching paintables from DOM nodes within shadow subtrees. This appears to be the main reason that keyboard editing was doing immediate forced relayout: doing a full layout invalidation meant we'd build a new layout tree, which then hid the problem with with still-attached paintables. By detaching them before committing a new layout, we make it possible for keyboard editing to just use normal relayout, instead of full forced invalidation & relayout.
2024-03-17 19:11:50 +01:00
});
LibWeb: Prune old paintable pointers from layout tree after relayout When text paintables shift around in the tree due to line wrapping, we may end up in a situation where some text node does not generate a paintable (due to being all whitespace, for example), even though in the previous layout pass, it *did* generate a paintable. To prevent holding on to old paintables in such cases, we now do a pass in LayoutState::commit() where we explicitly detach all old paintables from the layout tree.
2023-08-29 16:27:16 +02:00
LibWeb: Generate a TextPaintable for every Layout::TextNode This is prep work for moving event handling over to the painting tree.
2022-03-10 16:46:44 +01:00
HashTable<Layout::TextNode*> text_nodes;
LibWeb: Replace InlinePaintable with PaintableWithLines created per line InlinePaintable was an ad-hoc paintable type required to support the fragmentation of inline nodes across multiple lines. It existed because there was no way to associate multiple paintables with a single layout node. This resulted in a lot of duplicated code between PaintableBox and InlinePaintable. For example, most of the CSS properties like background, border, shadows, etc. and hit-testing are almost identical for both of them. However, the code had to be duplicated to account for the fact that InlinePaintable creates a box for each line. And we had quite many places that operate on paintables with a code like: ``` if (box.is_paintable_box()) { // do something } else (box.is_inline_paintable()) { // do exactly the same as for paintable box but using InlinePaintable } ``` This change replaces the usage of `InlinePaintable` with `PaintableWithLines` created for each line, which is now possible because we support having multiple paintables per layout node. By doing that, we remove lots of duplicated code and bring our implementation closer to the spec.
2024-10-13 21:29:47 +02:00
HashTable<Painting::PaintableWithLines*> inline_node_paintables;
LibWeb: Misc. code cleanup of LayoutState No functional changes.
2025-08-29 11:00:35 +02:00
auto transfer_box_model_metrics = [](Painting::BoxModelMetrics& box_model, UsedValues const& used_values) {
LibWeb: Store final box model metrics in paint tree, not layout tree This was a weird case of layout results being stored in the layout tree instead of in the paint tree like everything else.
2025-02-17 13:54:36 +01:00
box_model.inset = { used_values.inset_top, used_values.inset_right, used_values.inset_bottom, used_values.inset_left };
box_model.padding = { used_values.padding_top, used_values.padding_right, used_values.padding_bottom, used_values.padding_left };
box_model.border = { used_values.border_top, used_values.border_right, used_values.border_bottom, used_values.border_left };
box_model.margin = { used_values.margin_top, used_values.margin_right, used_values.margin_bottom, used_values.margin_left };
};
LibWeb: Replace InlinePaintable with PaintableWithLines created per line InlinePaintable was an ad-hoc paintable type required to support the fragmentation of inline nodes across multiple lines. It existed because there was no way to associate multiple paintables with a single layout node. This resulted in a lot of duplicated code between PaintableBox and InlinePaintable. For example, most of the CSS properties like background, border, shadows, etc. and hit-testing are almost identical for both of them. However, the code had to be duplicated to account for the fact that InlinePaintable creates a box for each line. And we had quite many places that operate on paintables with a code like: ``` if (box.is_paintable_box()) { // do something } else (box.is_inline_paintable()) { // do exactly the same as for paintable box but using InlinePaintable } ``` This change replaces the usage of `InlinePaintable` with `PaintableWithLines` created for each line, which is now possible because we support having multiple paintables per layout node. By doing that, we remove lots of duplicated code and bring our implementation closer to the spec.
2024-10-13 21:29:47 +02:00
auto try_to_relocate_fragment_in_inline_node = [&](auto& fragment, size_t line_index) -> bool {
for (auto const* parent = fragment.layout_node().parent(); parent; parent = parent->parent()) {
LibWeb: Don't relocate fragments across atomic inline boundary All fragments inside an atomic inline box should stay within that box, otherwise we'll screw up the paint order and paint them behind things that they're supposed to be on top of. This fixes an issue with inline-block content not appearing on sites like Google Docs and Reddit, among others.
2025-08-24 17:34:46 +02:00
if (parent->is_atomic_inline())
break;
LibWeb: Replace InlinePaintable with PaintableWithLines created per line InlinePaintable was an ad-hoc paintable type required to support the fragmentation of inline nodes across multiple lines. It existed because there was no way to associate multiple paintables with a single layout node. This resulted in a lot of duplicated code between PaintableBox and InlinePaintable. For example, most of the CSS properties like background, border, shadows, etc. and hit-testing are almost identical for both of them. However, the code had to be duplicated to account for the fact that InlinePaintable creates a box for each line. And we had quite many places that operate on paintables with a code like: ``` if (box.is_paintable_box()) { // do something } else (box.is_inline_paintable()) { // do exactly the same as for paintable box but using InlinePaintable } ``` This change replaces the usage of `InlinePaintable` with `PaintableWithLines` created for each line, which is now possible because we support having multiple paintables per layout node. By doing that, we remove lots of duplicated code and bring our implementation closer to the spec.
2024-10-13 21:29:47 +02:00
if (is<InlineNode>(*parent)) {
auto& inline_node = const_cast<InlineNode&>(static_cast<InlineNode const&>(*parent));
auto line_paintable = inline_node.create_paintable_for_line_with_index(line_index);
line_paintable->add_fragment(fragment);
LibWeb: Store final box model metrics in paint tree, not layout tree This was a weird case of layout results being stored in the layout tree instead of in the paint tree like everything else.
2025-02-17 13:54:36 +01:00
if (auto const* used_values = used_values_per_layout_node.get(inline_node).value_or(nullptr))
transfer_box_model_metrics(line_paintable->box_model(), *used_values);
LibWeb: Replace InlinePaintable with PaintableWithLines created per line InlinePaintable was an ad-hoc paintable type required to support the fragmentation of inline nodes across multiple lines. It existed because there was no way to associate multiple paintables with a single layout node. This resulted in a lot of duplicated code between PaintableBox and InlinePaintable. For example, most of the CSS properties like background, border, shadows, etc. and hit-testing are almost identical for both of them. However, the code had to be duplicated to account for the fact that InlinePaintable creates a box for each line. And we had quite many places that operate on paintables with a code like: ``` if (box.is_paintable_box()) { // do something } else (box.is_inline_paintable()) { // do exactly the same as for paintable box but using InlinePaintable } ``` This change replaces the usage of `InlinePaintable` with `PaintableWithLines` created for each line, which is now possible because we support having multiple paintables per layout node. By doing that, we remove lots of duplicated code and bring our implementation closer to the spec.
2024-10-13 21:29:47 +02:00
if (!inline_node_paintables.contains(line_paintable.ptr())) {
inline_node_paintables.set(line_paintable.ptr());
inline_node.add_paintable(line_paintable);
}
return true;
}
}
return false;
};
LibWeb: Add LineBox::absolute_rect() Let's just calculate this once, at the end of a layout, and then never have to worry about it again during painting.
2023-07-12 15:41:30 +02:00
LibWeb: Make LayoutState use HashMap instead of potentially huge Vector 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.
2023-05-23 07:47:37 +02:00
for (auto& it : used_values_per_layout_node) {
auto& used_values = *it.value;
LibWeb: Misc. code cleanup of LayoutState No functional changes.
2025-08-29 11:00:35 +02:00
auto& node = used_values.node();
LibWeb: Relax restrictions on LayoutState::get() input type Instead of only letting NodeWithStyleAndBoxModelMetrics (and subclasses) have used values in the layout state, we now allow any NodeWithStyle.
2023-09-04 12:24:48 +02:00
LibWeb: Make the paint tree a proper standalone tree Until now, paint trees have been piggybacking on the layout tree for traversal, and paintables didn't actually have their own parent/child pointers. This patch changes that by making Paintable inherit from TreeNode, and adding a new pass to LayoutState::commit() where we recursively build the new paint tree.
2023-08-18 12:30:27 +02:00
auto paintable = node.create_paintable();
LibWeb: Allow layout nodes to have multiple paintables CSS fragmentation implies 1:N relationship between layout nodes and paintables. This change is a preparation for implementation of inline fragmentation where InlinePaintable will be replaced with PaintableWithLines corresponding to each line.
2024-10-14 16:07:56 +02:00
node.add_paintable(paintable);
LibWeb: Split Paintable into Paintable and PaintableBox To prepare for paintable inline content, we take the basic painting functionality and hoist it into a base class.
2022-03-10 15:50:57 +01:00
LibWeb: Add Painting::Box and move things from Layout::Box into it The "paintable" state in Layout::Box was actually not safe to access until after layout had been performed. As a first step towards making this harder to mess up accidentally, this patch moves painting information from Layout::Box to a new class: Painting::Box. Every layout can have a corresponding paint box, and it holds the final used metrics determined by layout. The paint box is created and populated by FormattingState::commit(). I've also added DOM::Node::paint_box() as a convenient way to access the paint box (if available) of a given DOM node. Going forward, I believe this will allow us to better separate data that belongs to layout vs painting, and also open up opportunities for naturally invalidating caches in the paint box (since it's reconstituted by every layout.)
2022-03-09 23:53:41 +01:00
// For boxes, transfer all the state needed for painting.
LibWeb: Misc. code cleanup of LayoutState No functional changes.
2025-08-29 11:00:35 +02:00
if (auto* paintable_box = as_if<Painting::PaintableBox>(paintable.ptr())) {
transfer_box_model_metrics(paintable_box->box_model(), used_values);
LibWeb: Store final box model metrics in paint tree, not layout tree This was a weird case of layout results being stored in the layout tree instead of in the paint tree like everything else.
2025-02-17 13:54:36 +01:00
LibWeb: Misc. code cleanup of LayoutState No functional changes.
2025-08-29 11:00:35 +02:00
paintable_box->set_offset(used_values.offset);
paintable_box->set_content_size(used_values.content_width(), used_values.content_height());
if (used_values.override_borders_data().has_value())
paintable_box->set_override_borders_data(used_values.override_borders_data().value());
if (used_values.table_cell_coordinates().has_value())
paintable_box->set_table_cell_coordinates(used_values.table_cell_coordinates().value());
LibWeb: Make Painting::Box virtual and add Painting::BoxWithLines BlockContainer paint boxes are the only ones that have line boxes associated, so let's not waste memory on line boxes in all the other types of boxes. This also adds Layout::Box::paint_box() and the more tightly typed Layout::BlockContainer::paint_box() to get at the paint box from the corresponding layout box.
2022-03-10 11:12:06 +01:00
LibWeb: Misc. code cleanup of LayoutState No functional changes.
2025-08-29 11:00:35 +02:00
if (auto* paintable_with_lines = as_if<Painting::PaintableWithLines>(*paintable_box)) {
LibWeb: Replace InlinePaintable with PaintableWithLines created per line InlinePaintable was an ad-hoc paintable type required to support the fragmentation of inline nodes across multiple lines. It existed because there was no way to associate multiple paintables with a single layout node. This resulted in a lot of duplicated code between PaintableBox and InlinePaintable. For example, most of the CSS properties like background, border, shadows, etc. and hit-testing are almost identical for both of them. However, the code had to be duplicated to account for the fact that InlinePaintable creates a box for each line. And we had quite many places that operate on paintables with a code like: ``` if (box.is_paintable_box()) { // do something } else (box.is_inline_paintable()) { // do exactly the same as for paintable box but using InlinePaintable } ``` This change replaces the usage of `InlinePaintable` with `PaintableWithLines` created for each line, which is now possible because we support having multiple paintables per layout node. By doing that, we remove lots of duplicated code and bring our implementation closer to the spec.
2024-10-13 21:29:47 +02:00
for (size_t line_index = 0; line_index < used_values.line_boxes.size(); ++line_index) {
auto& line_box = used_values.line_boxes[line_index];
LibWeb: Store correct text offsets in PaintableFragment Previously, we were collapsing whitespace in Layout::TextNode and then passed the resulting string for further processing through ChunkIterator -> InlineLevelIterator -> InlineFormattingContext -> LineBuilder -> LineBoxFragment -> PaintableFragment. Our painting tree is where we deal with things like range offsets into the underlying text nodes, but since we modified the original string, the offsets were wrong. This changes the way we generate fragments: * Layout::TextNode no longer collapses whitespace as part of its stored "text for rendering", but moves this logic to ChunkIterator which splits up this text into separate views whenever whitespace needs to be collapsed. * Layout::LineBox now only extends the last fragment if its end offset is equal to the new fragment's start offset. Otherwise, there's a gap caused by collapsing whitespace and we need to generate a separate fragment for that in order to have a correct start offset. Some tests need new baselines because of the fixed start offsets. Fixes #566.
2025-09-12 10:06:27 +02:00
for (auto const& fragment : line_box.fragments()) {
LibWeb: Misc. code cleanup of LayoutState No functional changes.
2025-08-29 11:00:35 +02:00
if (auto const* text_node = as_if<TextNode>(fragment.layout_node()))
text_nodes.set(const_cast<TextNode*>(text_node));
LibWeb: Replace InlinePaintable with PaintableWithLines created per line InlinePaintable was an ad-hoc paintable type required to support the fragmentation of inline nodes across multiple lines. It existed because there was no way to associate multiple paintables with a single layout node. This resulted in a lot of duplicated code between PaintableBox and InlinePaintable. For example, most of the CSS properties like background, border, shadows, etc. and hit-testing are almost identical for both of them. However, the code had to be duplicated to account for the fact that InlinePaintable creates a box for each line. And we had quite many places that operate on paintables with a code like: ``` if (box.is_paintable_box()) { // do something } else (box.is_inline_paintable()) { // do exactly the same as for paintable box but using InlinePaintable } ``` This change replaces the usage of `InlinePaintable` with `PaintableWithLines` created for each line, which is now possible because we support having multiple paintables per layout node. By doing that, we remove lots of duplicated code and bring our implementation closer to the spec.
2024-10-13 21:29:47 +02:00
auto did_relocate_fragment = try_to_relocate_fragment_in_inline_node(fragment, line_index);
LibWeb: Misc. code cleanup of LayoutState No functional changes.
2025-08-29 11:00:35 +02:00
if (!did_relocate_fragment)
paintable_with_lines->add_fragment(fragment);
LibWeb: Replace InlinePaintable with PaintableWithLines created per line InlinePaintable was an ad-hoc paintable type required to support the fragmentation of inline nodes across multiple lines. It existed because there was no way to associate multiple paintables with a single layout node. This resulted in a lot of duplicated code between PaintableBox and InlinePaintable. For example, most of the CSS properties like background, border, shadows, etc. and hit-testing are almost identical for both of them. However, the code had to be duplicated to account for the fact that InlinePaintable creates a box for each line. And we had quite many places that operate on paintables with a code like: ``` if (box.is_paintable_box()) { // do something } else (box.is_inline_paintable()) { // do exactly the same as for paintable box but using InlinePaintable } ``` This change replaces the usage of `InlinePaintable` with `PaintableWithLines` created for each line, which is now possible because we support having multiple paintables per layout node. By doing that, we remove lots of duplicated code and bring our implementation closer to the spec.
2024-10-13 21:29:47 +02:00
}
LibWeb: Use separate structure to represent fragments in paintable tree This is a part of refactoring towards making the paintable tree independent of the layout tree. Now, instead of transferring text fragments from the layout tree to the paintable tree during the layout commit phase, we allocate separate PaintableFragments that contain only the information necessary for painting. Doing this also allows us to get rid LineBoxes, as they are used only during layout.
2024-01-12 21:25:05 +01:00
}
LibWeb: Add LineBox::absolute_rect() Let's just calculate this once, at the end of a layout, and then never have to worry about it again during painting.
2023-07-12 15:41:30 +02:00
}
LibWeb: Store computed SVG path data/transforms in LayoutState This removes the awkward hack to recompute the layout transform at paint time, and makes it possible for path sizes to be computed during layout. For example, it's possible to use relative units in SVG shapes (e.g. <rect>), which can be resolved during layout, but would be hard to resolve again during painting.
2023-10-29 17:08:35 +00:00
LibWeb: Misc. code cleanup of LayoutState No functional changes.
2025-08-29 11:00:35 +02:00
if (auto* svg_graphics_paintable = as_if<Painting::SVGGraphicsPaintable>(paintable.ptr());
svg_graphics_paintable && used_values.computed_svg_transforms().has_value()) {
svg_graphics_paintable->set_computed_transforms(*used_values.computed_svg_transforms());
LibWeb: Layout SVG <text> elements during layout (not while painting) Previously, all SVG <text> elements were zero-sized boxes, that were only actually positioned and sized during painting. This led to a number of problems, the most visible of which being that text could not be scaled based on the viewBox. Which this patch, <text> elements get a correctly sized layout box, that can be hit-tested and respects the SVG viewBox. To share code with SVGGeometryElement's the PathData (from the prior commit) has been split into a computed path and computed transforms. The computed path is specific to geometry elements, but the computed transforms are shared between all SVG graphics elements.
2023-10-29 19:11:46 +00:00
}
LibWeb: Misc. code cleanup of LayoutState No functional changes.
2025-08-29 11:00:35 +02:00
if (auto* svg_path_paintable = as_if<Painting::SVGPathPaintable>(paintable.ptr());
svg_path_paintable && used_values.computed_svg_path().has_value()) {
svg_path_paintable->set_computed_path(move(*used_values.computed_svg_path()));
LibWeb: Store computed SVG path data/transforms in LayoutState This removes the awkward hack to recompute the layout transform at paint time, and makes it possible for path sizes to be computed during layout. For example, it's possible to use relative units in SVG shapes (e.g. <rect>), which can be resolved during layout, but would be hard to resolve again during painting.
2023-10-29 17:08:35 +00:00
}
LibWeb: Return used values for grid tracks in getComputedStyle() That's awkward, but getComputedStyle needs to return used track values for gridTemplateColumns and gridTemplateRows properties. This change implements it by saving style values with used values into layout state, so it could be assigned to paintables during LayoutState::commit() and later accessed by style_value_for_property(). I haven't seen it used in the wild, but WPT grid tests extensively use it. For example this change helps to go from 0/10 to 8/10 on this test: https://wpt.live/css/css-grid/layout-algorithm/grid-fit-content-percentage.html
2024-09-09 12:15:49 +02:00
if (node.display().is_grid_inside()) {
LibWeb: Misc. code cleanup of LayoutState No functional changes.
2025-08-29 11:00:35 +02:00
paintable_box->set_used_values_for_grid_template_columns(used_values.grid_template_columns());
paintable_box->set_used_values_for_grid_template_rows(used_values.grid_template_rows());
LibWeb: Return used values for grid tracks in getComputedStyle() That's awkward, but getComputedStyle needs to return used track values for gridTemplateColumns and gridTemplateRows properties. This change implements it by saving style values with used values into layout state, so it could be assigned to paintables during LayoutState::commit() and later accessed by style_value_for_property(). I haven't seen it used in the wild, but WPT grid tests extensively use it. For example this change helps to go from 0/10 to 8/10 on this test: https://wpt.live/css/css-grid/layout-algorithm/grid-fit-content-percentage.html
2024-09-09 12:15:49 +02:00
}
LibWeb: Add LineBox::absolute_rect() Let's just calculate this once, at the end of a layout, and then never have to worry about it again during painting.
2023-07-12 15:41:30 +02:00
}
}
LibWeb: Replace InlinePaintable with PaintableWithLines created per line InlinePaintable was an ad-hoc paintable type required to support the fragmentation of inline nodes across multiple lines. It existed because there was no way to associate multiple paintables with a single layout node. This resulted in a lot of duplicated code between PaintableBox and InlinePaintable. For example, most of the CSS properties like background, border, shadows, etc. and hit-testing are almost identical for both of them. However, the code had to be duplicated to account for the fact that InlinePaintable creates a box for each line. And we had quite many places that operate on paintables with a code like: ``` if (box.is_paintable_box()) { // do something } else (box.is_inline_paintable()) { // do exactly the same as for paintable box but using InlinePaintable } ``` This change replaces the usage of `InlinePaintable` with `PaintableWithLines` created for each line, which is now possible because we support having multiple paintables per layout node. By doing that, we remove lots of duplicated code and bring our implementation closer to the spec.
2024-10-13 21:29:47 +02:00
// Create paintables for inline nodes without fragments to make possible querying their geometry.
for (auto& inline_node : inline_nodes) {
LibWeb: Misc. code cleanup of LayoutState No functional changes.
2025-08-29 11:00:35 +02:00
if (inline_node->first_paintable())
LibWeb: Replace InlinePaintable with PaintableWithLines created per line InlinePaintable was an ad-hoc paintable type required to support the fragmentation of inline nodes across multiple lines. It existed because there was no way to associate multiple paintables with a single layout node. This resulted in a lot of duplicated code between PaintableBox and InlinePaintable. For example, most of the CSS properties like background, border, shadows, etc. and hit-testing are almost identical for both of them. However, the code had to be duplicated to account for the fact that InlinePaintable creates a box for each line. And we had quite many places that operate on paintables with a code like: ``` if (box.is_paintable_box()) { // do something } else (box.is_inline_paintable()) { // do exactly the same as for paintable box but using InlinePaintable } ``` This change replaces the usage of `InlinePaintable` with `PaintableWithLines` created for each line, which is now possible because we support having multiple paintables per layout node. By doing that, we remove lots of duplicated code and bring our implementation closer to the spec.
2024-10-13 21:29:47 +02:00
continue;
LibWeb: Misc. code cleanup of LayoutState No functional changes.
2025-08-29 11:00:35 +02:00
LibWeb: Improve painting of nested inline elements PaintableWithLines created from inline nodes need to examine their children to fully compute their size and offset as nested children might have textnodes that are placed before their parent. Fixes #1286
2024-11-22 10:54:00 +01:00
auto line_paintable = inline_node->create_paintable_for_line_with_index(0);
inline_node->add_paintable(line_paintable);
inline_node_paintables.set(line_paintable.ptr());
LibWeb: Store final box model metrics in paint tree, not layout tree This was a weird case of layout results being stored in the layout tree instead of in the paint tree like everything else.
2025-02-17 13:54:36 +01:00
if (auto const* used_values = used_values_per_layout_node.get(*inline_node).value_or(nullptr))
transfer_box_model_metrics(line_paintable->box_model(), *used_values);
LibWeb: Replace InlinePaintable with PaintableWithLines created per line InlinePaintable was an ad-hoc paintable type required to support the fragmentation of inline nodes across multiple lines. It existed because there was no way to associate multiple paintables with a single layout node. This resulted in a lot of duplicated code between PaintableBox and InlinePaintable. For example, most of the CSS properties like background, border, shadows, etc. and hit-testing are almost identical for both of them. However, the code had to be duplicated to account for the fact that InlinePaintable creates a box for each line. And we had quite many places that operate on paintables with a code like: ``` if (box.is_paintable_box()) { // do something } else (box.is_inline_paintable()) { // do exactly the same as for paintable box but using InlinePaintable } ``` This change replaces the usage of `InlinePaintable` with `PaintableWithLines` created for each line, which is now possible because we support having multiple paintables per layout node. By doing that, we remove lots of duplicated code and bring our implementation closer to the spec.
2024-10-13 21:29:47 +02:00
}
LibWeb: Resolve relpos fragment offsets only for inline paintables Prior to this change, we iterated through all fragments within each PaintableWithLines to resolve the relative position offset. This happened before transferring the fragments to their corresponding inline paintables. With this change, we significantly reduce amount of work by attempting to resolve relative position offsets only for those contained within inline paintables. Performance improvement on https://html.spec.whatwg.org/
2024-01-18 14:03:30 +01:00
// Resolve relative positions for regular boxes (not line box fragments):
// NOTE: This needs to occur before fragments are transferred into the corresponding inline paintables, because
// after this transfer, the containing_line_box_fragment will no longer be valid.
for (auto& it : used_values_per_layout_node) {
auto& used_values = *it.value;
auto& node = const_cast<NodeWithStyle&>(used_values.node());
if (!node.is_box())
continue;
LibWeb: Store final box model metrics in paint tree, not layout tree This was a weird case of layout results being stored in the layout tree instead of in the paint tree like everything else.
2025-02-17 13:54:36 +01:00
auto& paintable = as<Painting::PaintableBox>(*node.first_paintable());
LibWeb: Resolve relpos fragment offsets only for inline paintables Prior to this change, we iterated through all fragments within each PaintableWithLines to resolve the relative position offset. This happened before transferring the fragments to their corresponding inline paintables. With this change, we significantly reduce amount of work by attempting to resolve relative position offsets only for those contained within inline paintables. Performance improvement on https://html.spec.whatwg.org/
2024-01-18 14:03:30 +01:00
CSSPixelPoint offset;
if (used_values.containing_line_box_fragment.has_value()) {
// Atomic inline case:
// We know that `node` is an atomic inline because `containing_line_box_fragments` refers to the
// line box fragment in the parent block container that contains it.
auto const& containing_line_box_fragment = used_values.containing_line_box_fragment.value();
auto const& containing_block = *node.containing_block();
auto const& containing_block_used_values = get(containing_block);
auto const& fragment = containing_block_used_values.line_boxes[containing_line_box_fragment.line_box_index].fragments()[containing_line_box_fragment.fragment_index];
// The fragment has the final offset for the atomic inline, so we just need to copy it from there.
offset = fragment.offset();
} else {
// Not an atomic inline, much simpler case.
offset = used_values.offset;
}
LibWeb: Misc. code cleanup of LayoutState No functional changes.
2025-08-29 11:00:35 +02:00
LibWeb: Resolve relpos fragment offsets only for inline paintables Prior to this change, we iterated through all fragments within each PaintableWithLines to resolve the relative position offset. This happened before transferring the fragments to their corresponding inline paintables. With this change, we significantly reduce amount of work by attempting to resolve relative position offsets only for those contained within inline paintables. Performance improvement on https://html.spec.whatwg.org/
2024-01-18 14:03:30 +01:00
// Apply relative position inset if appropriate.
if (node.computed_values().position() == CSS::Positioning::Relative && is<NodeWithStyleAndBoxModelMetrics>(node)) {
LibWeb: Store final box model metrics in paint tree, not layout tree This was a weird case of layout results being stored in the layout tree instead of in the paint tree like everything else.
2025-02-17 13:54:36 +01:00
auto const& inset = paintable.box_model().inset;
LibWeb: Resolve relpos fragment offsets only for inline paintables Prior to this change, we iterated through all fragments within each PaintableWithLines to resolve the relative position offset. This happened before transferring the fragments to their corresponding inline paintables. With this change, we significantly reduce amount of work by attempting to resolve relative position offsets only for those contained within inline paintables. Performance improvement on https://html.spec.whatwg.org/
2024-01-18 14:03:30 +01:00
offset.translate_by(inset.left, inset.top);
}
paintable.set_offset(offset);
}
LibWeb: Resolve relative offsets *once* after layout Instead of applying relative offsets (like position:relative insets) during painting and hit testing, we now do a pass at the end of layout and assign the final resolved offsets to paintables. This makes painting and hit testing easier since they don't have to think about relative offsets, and it also fixes a bug where offsets were not applied to text fragments inside inline-flow elements that were themselves position:relative.
2023-08-15 15:11:10 +02:00
LibWeb: Misc. code cleanup of LayoutState No functional changes.
2025-08-29 11:00:35 +02:00
for (auto* text_node : text_nodes)
LibWeb: Allow layout nodes to have multiple paintables CSS fragmentation implies 1:N relationship between layout nodes and paintables. This change is a preparation for implementation of inline fragmentation where InlinePaintable will be replaced with PaintableWithLines corresponding to each line.
2024-10-14 16:07:56 +02:00
text_node->add_paintable(text_node->create_paintable());
LibWeb: Make the paint tree a proper standalone tree Until now, paint trees have been piggybacking on the layout tree for traversal, and paintables didn't actually have their own parent/child pointers. This patch changes that by making Paintable inherit from TreeNode, and adding a new pass to LayoutState::commit() where we recursively build the new paint tree.
2023-08-18 12:30:27 +02:00
build_paint_tree(root);
LibWeb: Resolve relpos fragment offsets only for inline paintables Prior to this change, we iterated through all fragments within each PaintableWithLines to resolve the relative position offset. This happened before transferring the fragments to their corresponding inline paintables. With this change, we significantly reduce amount of work by attempting to resolve relative position offsets only for those contained within inline paintables. Performance improvement on https://html.spec.whatwg.org/
2024-01-18 14:03:30 +01:00
resolve_relative_positions();
LibWeb: Replace InlinePaintable with PaintableWithLines created per line InlinePaintable was an ad-hoc paintable type required to support the fragmentation of inline nodes across multiple lines. It existed because there was no way to associate multiple paintables with a single layout node. This resulted in a lot of duplicated code between PaintableBox and InlinePaintable. For example, most of the CSS properties like background, border, shadows, etc. and hit-testing are almost identical for both of them. However, the code had to be duplicated to account for the fact that InlinePaintable creates a box for each line. And we had quite many places that operate on paintables with a code like: ``` if (box.is_paintable_box()) { // do something } else (box.is_inline_paintable()) { // do exactly the same as for paintable box but using InlinePaintable } ``` This change replaces the usage of `InlinePaintable` with `PaintableWithLines` created for each line, which is now possible because we support having multiple paintables per layout node. By doing that, we remove lots of duplicated code and bring our implementation closer to the spec.
2024-10-13 21:29:47 +02:00
// Measure size of paintables created for inline nodes.
LibWeb: Apply nested inline margin box sizes to inline layout nodes When committing the layout state, we now take nested inlines' margin, border and padding sizes into account. Fixes #3491.
2025-08-27 12:37:59 +02:00
for (auto* paintable_with_lines : inline_node_paintables) {
if (!is<InlineNode>(paintable_with_lines->layout_node()))
LibWeb: Replace InlinePaintable with PaintableWithLines created per line InlinePaintable was an ad-hoc paintable type required to support the fragmentation of inline nodes across multiple lines. It existed because there was no way to associate multiple paintables with a single layout node. This resulted in a lot of duplicated code between PaintableBox and InlinePaintable. For example, most of the CSS properties like background, border, shadows, etc. and hit-testing are almost identical for both of them. However, the code had to be duplicated to account for the fact that InlinePaintable creates a box for each line. And we had quite many places that operate on paintables with a code like: ``` if (box.is_paintable_box()) { // do something } else (box.is_inline_paintable()) { // do exactly the same as for paintable box but using InlinePaintable } ``` This change replaces the usage of `InlinePaintable` with `PaintableWithLines` created for each line, which is now possible because we support having multiple paintables per layout node. By doing that, we remove lots of duplicated code and bring our implementation closer to the spec.
2024-10-13 21:29:47 +02:00
continue;
LibWeb: Improve painting of nested inline elements PaintableWithLines created from inline nodes need to examine their children to fully compute their size and offset as nested children might have textnodes that are placed before their parent. Fixes #1286
2024-11-22 10:54:00 +01:00
Optional<CSSPixelPoint> offset;
CSSPixelSize size;
auto line_index = paintable_with_lines->line_index();
LibWeb: Apply nested inline margin box sizes to inline layout nodes When committing the layout state, we now take nested inlines' margin, border and padding sizes into account. Fixes #3491.
2025-08-27 12:37:59 +02:00
paintable_with_lines->for_each_in_inclusive_subtree_of_type<Painting::PaintableWithLines>([&](auto& paintable) {
if (paintable.line_index() != line_index)
return TraversalDecision::Continue;
LibWeb: Prevent creation of new UsedValues for nested inline nodes In LayoutState, used_values_per_layout_node should not be modified in order to determine inline nodes' dimensions - all the required values should already be in there. In 2585f2da0d1d2e3577f1b62aefcc14ca75216c73 we did accidentally create new values, causing the code further down to try and get a PaintableBox from an anonymous container and crashing. Fixes #6015.
2025-08-28 21:35:21 +02:00
auto used_values = used_values_per_layout_node.get(paintable.layout_node_with_style_and_box_metrics());
if (&paintable != paintable_with_lines && used_values.has_value())
size.set_width(size.width() + used_values.value()->margin_box_left() + used_values.value()->margin_box_right());
LibWeb: Apply nested inline margin box sizes to inline layout nodes When committing the layout state, we now take nested inlines' margin, border and padding sizes into account. Fixes #3491.
2025-08-27 12:37:59 +02:00
auto const& fragments = paintable.fragments();
if (!fragments.is_empty()) {
LibWeb: Prevent creation of new UsedValues for nested inline nodes In LayoutState, used_values_per_layout_node should not be modified in order to determine inline nodes' dimensions - all the required values should already be in there. In 2585f2da0d1d2e3577f1b62aefcc14ca75216c73 we did accidentally create new values, causing the code further down to try and get a PaintableBox from an anonymous container and crashing. Fixes #6015.
2025-08-28 21:35:21 +02:00
if (!offset.has_value() || (fragments.first().offset().x() < offset->x()))
LibWeb: Apply nested inline margin box sizes to inline layout nodes When committing the layout state, we now take nested inlines' margin, border and padding sizes into account. Fixes #3491.
2025-08-27 12:37:59 +02:00
offset = fragments.first().offset();
LibWeb: Prevent creation of new UsedValues for nested inline nodes In LayoutState, used_values_per_layout_node should not be modified in order to determine inline nodes' dimensions - all the required values should already be in there. In 2585f2da0d1d2e3577f1b62aefcc14ca75216c73 we did accidentally create new values, causing the code further down to try and get a PaintableBox from an anonymous container and crashing. Fixes #6015.
2025-08-28 21:35:21 +02:00
if (&paintable == paintable_with_lines->first_child() && used_values.has_value())
offset->translate_by(-used_values.value()->margin_box_left(), 0);
LibWeb: Improve painting of nested inline elements PaintableWithLines created from inline nodes need to examine their children to fully compute their size and offset as nested children might have textnodes that are placed before their parent. Fixes #1286
2024-11-22 10:54:00 +01:00
}
LibWeb: Apply nested inline margin box sizes to inline layout nodes When committing the layout state, we now take nested inlines' margin, border and padding sizes into account. Fixes #3491.
2025-08-27 12:37:59 +02:00
for (auto const& fragment : fragments)
size.set_width(size.width() + fragment.width());
LibWeb: Misc. code cleanup of LayoutState No functional changes.
2025-08-29 11:00:35 +02:00
LibWeb: Improve painting of nested inline elements PaintableWithLines created from inline nodes need to examine their children to fully compute their size and offset as nested children might have textnodes that are placed before their parent. Fixes #1286
2024-11-22 10:54:00 +01:00
return TraversalDecision::Continue;
});
if (offset.has_value()) {
LibWeb: Apply nested inline margin box sizes to inline layout nodes When committing the layout state, we now take nested inlines' margin, border and padding sizes into account. Fixes #3491.
2025-08-27 12:37:59 +02:00
if (!paintable_with_lines->fragments().is_empty())
LibWeb: Improve painting of nested inline elements PaintableWithLines created from inline nodes need to examine their children to fully compute their size and offset as nested children might have textnodes that are placed before their parent. Fixes #1286
2024-11-22 10:54:00 +01:00
offset.value().set_y(paintable_with_lines->fragments().first().offset().y());
LibWeb: Apply nested inline margin box sizes to inline layout nodes When committing the layout state, we now take nested inlines' margin, border and padding sizes into account. Fixes #3491.
2025-08-27 12:37:59 +02:00
LibWeb: Improve painting of nested inline elements PaintableWithLines created from inline nodes need to examine their children to fully compute their size and offset as nested children might have textnodes that are placed before their parent. Fixes #1286
2024-11-22 10:54:00 +01:00
// FIXME: If this paintable does not have any fragment we do no know the y offset. It should be where text should
// start if there had been any for this node. Pick y offset of the leftmost fragment in the inclusive subtree in the meantime.
paintable_with_lines->set_offset(offset.value());
LibWeb: Replace InlinePaintable with PaintableWithLines created per line InlinePaintable was an ad-hoc paintable type required to support the fragmentation of inline nodes across multiple lines. It existed because there was no way to associate multiple paintables with a single layout node. This resulted in a lot of duplicated code between PaintableBox and InlinePaintable. For example, most of the CSS properties like background, border, shadows, etc. and hit-testing are almost identical for both of them. However, the code had to be duplicated to account for the fact that InlinePaintable creates a box for each line. And we had quite many places that operate on paintables with a code like: ``` if (box.is_paintable_box()) { // do something } else (box.is_inline_paintable()) { // do exactly the same as for paintable box but using InlinePaintable } ``` This change replaces the usage of `InlinePaintable` with `PaintableWithLines` created for each line, which is now possible because we support having multiple paintables per layout node. By doing that, we remove lots of duplicated code and bring our implementation closer to the spec.
2024-10-13 21:29:47 +02:00
}
LibWeb: Improve painting of nested inline elements PaintableWithLines created from inline nodes need to examine their children to fully compute their size and offset as nested children might have textnodes that are placed before their parent. Fixes #1286
2024-11-22 10:54:00 +01:00
if (!paintable_with_lines->fragments().is_empty()) {
LibWeb: Misc. code cleanup of LayoutState No functional changes.
2025-08-29 11:00:35 +02:00
for (auto const& fragment : paintable_with_lines->fragments())
LibWeb: Improve painting of nested inline elements PaintableWithLines created from inline nodes need to examine their children to fully compute their size and offset as nested children might have textnodes that are placed before their parent. Fixes #1286
2024-11-22 10:54:00 +01:00
size.set_height(max(size.height(), fragment.height()));
} else {
size.set_height(paintable_with_lines->layout_node().computed_values().line_height());
LibWeb: Replace InlinePaintable with PaintableWithLines created per line InlinePaintable was an ad-hoc paintable type required to support the fragmentation of inline nodes across multiple lines. It existed because there was no way to associate multiple paintables with a single layout node. This resulted in a lot of duplicated code between PaintableBox and InlinePaintable. For example, most of the CSS properties like background, border, shadows, etc. and hit-testing are almost identical for both of them. However, the code had to be duplicated to account for the fact that InlinePaintable creates a box for each line. And we had quite many places that operate on paintables with a code like: ``` if (box.is_paintable_box()) { // do something } else (box.is_inline_paintable()) { // do exactly the same as for paintable box but using InlinePaintable } ``` This change replaces the usage of `InlinePaintable` with `PaintableWithLines` created for each line, which is now possible because we support having multiple paintables per layout node. By doing that, we remove lots of duplicated code and bring our implementation closer to the spec.
2024-10-13 21:29:47 +02:00
}
LibWeb: Improve painting of nested inline elements PaintableWithLines created from inline nodes need to examine their children to fully compute their size and offset as nested children might have textnodes that are placed before their parent. Fixes #1286
2024-11-22 10:54:00 +01:00
LibWeb: Apply nested inline margin box sizes to inline layout nodes When committing the layout state, we now take nested inlines' margin, border and padding sizes into account. Fixes #3491.
2025-08-27 12:37:59 +02:00
paintable_with_lines->set_content_size(size);
LibWeb: Replace InlinePaintable with PaintableWithLines created per line InlinePaintable was an ad-hoc paintable type required to support the fragmentation of inline nodes across multiple lines. It existed because there was no way to associate multiple paintables with a single layout node. This resulted in a lot of duplicated code between PaintableBox and InlinePaintable. For example, most of the CSS properties like background, border, shadows, etc. and hit-testing are almost identical for both of them. However, the code had to be duplicated to account for the fact that InlinePaintable creates a box for each line. And we had quite many places that operate on paintables with a code like: ``` if (box.is_paintable_box()) { // do something } else (box.is_inline_paintable()) { // do exactly the same as for paintable box but using InlinePaintable } ``` This change replaces the usage of `InlinePaintable` with `PaintableWithLines` created for each line, which is now possible because we support having multiple paintables per layout node. By doing that, we remove lots of duplicated code and bring our implementation closer to the spec.
2024-10-13 21:29:47 +02:00
}
LibWeb: Measure the overflow for all scroll containers Instead of just measuring the layout viewport, we now measure overflow in every box that is a scroll container. This has the side effect of no longer creating paintables for layout boxes that didn't participate in layout. (For example, empty/anonymous boxes that were ignored by flex itemization.) Such boxes are now marked as "(not painted)" in the layout tree dumps, as they have no paintable to dump geometry from.
2023-05-29 08:53:39 +02:00
// Measure overflow in scroll containers.
for (auto& it : used_values_per_layout_node) {
auto& used_values = *it.value;
LibWeb: Apply nested inline margin box sizes to inline layout nodes When committing the layout state, we now take nested inlines' margin, border and padding sizes into account. Fixes #3491.
2025-08-27 12:37:59 +02:00
auto const* box = as_if<Box>(used_values.node());
if (!box)
LibWeb: Measure the overflow for all scroll containers Instead of just measuring the layout viewport, we now measure overflow in every box that is a scroll container. This has the side effect of no longer creating paintables for layout boxes that didn't participate in layout. (For example, empty/anonymous boxes that were ignored by flex itemization.) Such boxes are now marked as "(not painted)" in the layout tree dumps, as they have no paintable to dump geometry from.
2023-05-29 08:53:39 +02:00
continue;
LibWeb: Apply nested inline margin box sizes to inline layout nodes When committing the layout state, we now take nested inlines' margin, border and padding sizes into account. Fixes #3491.
2025-08-27 12:37:59 +02:00
measure_scrollable_overflow(*box);
LibWeb: Clamp scroll offset into valid range after relayout If the layout has been recalculated and the sizes of scrollable overflow rectangles could have changed, we need to ensure that scroll offsets remain within the valid range.
2024-02-22 02:09:16 +01:00
// The scroll offset can become invalid if the scrollable overflow rectangle has changed after layout.
// For example, if the scroll container has been scrolled to the very end and is then resized to become larger
// (scrollable overflow rect become smaller), the scroll offset would be out of bounds.
LibWeb: Apply nested inline margin box sizes to inline layout nodes When committing the layout state, we now take nested inlines' margin, border and padding sizes into account. Fixes #3491.
2025-08-27 12:37:59 +02:00
auto& paintable_box = const_cast<Painting::PaintableBox&>(*box->paintable_box());
LibWeb: Clamp scroll offset into valid range after relayout If the layout has been recalculated and the sizes of scrollable overflow rectangles could have changed, we need to ensure that scroll offsets remain within the valid range.
2024-02-22 02:09:16 +01:00
if (!paintable_box.scroll_offset().is_zero())
LibWeb: Don't class mousewheel as handled if scroll offset isn't updated Before this change, you could only scroll the current hovered scroll container, even if it was at the beginning or end and thus having no effect. Now, if it doesn't update, it will not be classed as handled and will move onto the next scroll container.
2025-10-07 14:09:30 +01:00
(void)paintable_box.set_scroll_offset(paintable_box.scroll_offset());
LibWeb: Resolve "position: sticky" insets relative to scrollport Reading of https://drafts.csswg.org/css-position revealed I was wrong assuming sticky insets need to be resolved relative to containing block.
2024-09-02 20:46:41 +02:00
}
for (auto& it : used_values_per_layout_node) {
auto& used_values = *it.value;
LibWeb: Assign sticky insets to Layout::InlineNode Before this change we were ignoring boxes with `display: inline` while assigning sticky insets. This was not correct because inline boxes are allowed to have sticky positioning. Fixes: https://github.com/LadybirdBrowser/ladybird/issues/3718 https://github.com/LadybirdBrowser/ladybird/issues/3507 https://github.com/LadybirdBrowser/ladybird/issues/3133
2025-02-27 16:56:43 +01:00
auto& node = used_values.node();
for (auto& paintable : node.paintables()) {
LibWeb: Misc. code cleanup of LayoutState No functional changes.
2025-08-29 11:00:35 +02:00
auto* paintable_box = as_if<Painting::PaintableBox>(paintable);
LibWeb: Assign sticky insets to Layout::InlineNode Before this change we were ignoring boxes with `display: inline` while assigning sticky insets. This was not correct because inline boxes are allowed to have sticky positioning. Fixes: https://github.com/LadybirdBrowser/ladybird/issues/3718 https://github.com/LadybirdBrowser/ladybird/issues/3507 https://github.com/LadybirdBrowser/ladybird/issues/3133
2025-02-27 16:56:43 +01:00
if (!paintable_box)
continue;
LibWeb: Add "position: sticky" support 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.
2024-08-24 19:20:31 +02:00
LibWeb: Assign sticky insets to Layout::InlineNode Before this change we were ignoring boxes with `display: inline` while assigning sticky insets. This was not correct because inline boxes are allowed to have sticky positioning. Fixes: https://github.com/LadybirdBrowser/ladybird/issues/3718 https://github.com/LadybirdBrowser/ladybird/issues/3507 https://github.com/LadybirdBrowser/ladybird/issues/3133
2025-02-27 16:56:43 +01:00
if (node.is_sticky_position()) {
// https://drafts.csswg.org/css-position/#insets
LibWeb: Misc. code cleanup of LayoutState No functional changes.
2025-08-29 11:00:35 +02:00
// For sticky positioned boxes, the inset is instead relative to the relevant scrollport’s size.
// Negative values are allowed.
LibWeb: Resolve "position: sticky" insets relative to scrollport Reading of https://drafts.csswg.org/css-position revealed I was wrong assuming sticky insets need to be resolved relative to containing block.
2024-09-02 20:46:41 +02:00
LibWeb: Assign sticky insets to Layout::InlineNode Before this change we were ignoring boxes with `display: inline` while assigning sticky insets. This was not correct because inline boxes are allowed to have sticky positioning. Fixes: https://github.com/LadybirdBrowser/ladybird/issues/3718 https://github.com/LadybirdBrowser/ladybird/issues/3507 https://github.com/LadybirdBrowser/ladybird/issues/3133
2025-02-27 16:56:43 +01:00
auto sticky_insets = make<Painting::PaintableBox::StickyInsets>();
auto const& inset = node.computed_values().inset();
LibWeb: Resolve "position: sticky" insets relative to scrollport Reading of https://drafts.csswg.org/css-position revealed I was wrong assuming sticky insets need to be resolved relative to containing block.
2024-09-02 20:46:41 +02:00
LibWeb: Assign sticky insets to Layout::InlineNode Before this change we were ignoring boxes with `display: inline` while assigning sticky insets. This was not correct because inline boxes are allowed to have sticky positioning. Fixes: https://github.com/LadybirdBrowser/ladybird/issues/3718 https://github.com/LadybirdBrowser/ladybird/issues/3507 https://github.com/LadybirdBrowser/ladybird/issues/3133
2025-02-27 16:56:43 +01:00
auto const* nearest_scrollable_ancestor = paintable_box->nearest_scrollable_ancestor();
CSSPixelSize scrollport_size;
LibWeb: Misc. code cleanup of LayoutState No functional changes.
2025-08-29 11:00:35 +02:00
if (nearest_scrollable_ancestor)
LibWeb: Assign sticky insets to Layout::InlineNode Before this change we were ignoring boxes with `display: inline` while assigning sticky insets. This was not correct because inline boxes are allowed to have sticky positioning. Fixes: https://github.com/LadybirdBrowser/ladybird/issues/3718 https://github.com/LadybirdBrowser/ladybird/issues/3507 https://github.com/LadybirdBrowser/ladybird/issues/3133
2025-02-27 16:56:43 +01:00
scrollport_size = nearest_scrollable_ancestor->absolute_rect().size();
LibWeb: Resolve "position: sticky" insets relative to scrollport Reading of https://drafts.csswg.org/css-position revealed I was wrong assuming sticky insets need to be resolved relative to containing block.
2024-09-02 20:46:41 +02:00
LibWeb: Misc. code cleanup of LayoutState No functional changes.
2025-08-29 11:00:35 +02:00
if (!inset.top().is_auto())
LibWeb: Make LengthBox hold LengthPercentageOrAuto Not every user of this requires an `auto` state, but most do. This has quite a big diff but most of that is mechanical: LengthPercentageOrAuto has `resolved_or_auto()` instead of `resolved()`, and `to_px_or_zero()` instead of `to_px()`, to make their output clearer.
2025-09-01 12:51:52 +01:00
sticky_insets->top = inset.top().to_px_or_zero(node, scrollport_size.height());
LibWeb: Misc. code cleanup of LayoutState No functional changes.
2025-08-29 11:00:35 +02:00
if (!inset.right().is_auto())
LibWeb: Make LengthBox hold LengthPercentageOrAuto Not every user of this requires an `auto` state, but most do. This has quite a big diff but most of that is mechanical: LengthPercentageOrAuto has `resolved_or_auto()` instead of `resolved()`, and `to_px_or_zero()` instead of `to_px()`, to make their output clearer.
2025-09-01 12:51:52 +01:00
sticky_insets->right = inset.right().to_px_or_zero(node, scrollport_size.width());
LibWeb: Misc. code cleanup of LayoutState No functional changes.
2025-08-29 11:00:35 +02:00
if (!inset.bottom().is_auto())
LibWeb: Make LengthBox hold LengthPercentageOrAuto Not every user of this requires an `auto` state, but most do. This has quite a big diff but most of that is mechanical: LengthPercentageOrAuto has `resolved_or_auto()` instead of `resolved()`, and `to_px_or_zero()` instead of `to_px()`, to make their output clearer.
2025-09-01 12:51:52 +01:00
sticky_insets->bottom = inset.bottom().to_px_or_zero(node, scrollport_size.height());
LibWeb: Misc. code cleanup of LayoutState No functional changes.
2025-08-29 11:00:35 +02:00
if (!inset.left().is_auto())
LibWeb: Make LengthBox hold LengthPercentageOrAuto Not every user of this requires an `auto` state, but most do. This has quite a big diff but most of that is mechanical: LengthPercentageOrAuto has `resolved_or_auto()` instead of `resolved()`, and `to_px_or_zero()` instead of `to_px()`, to make their output clearer.
2025-09-01 12:51:52 +01:00
sticky_insets->left = inset.left().to_px_or_zero(node, scrollport_size.width());
LibWeb: Assign sticky insets to Layout::InlineNode Before this change we were ignoring boxes with `display: inline` while assigning sticky insets. This was not correct because inline boxes are allowed to have sticky positioning. Fixes: https://github.com/LadybirdBrowser/ladybird/issues/3718 https://github.com/LadybirdBrowser/ladybird/issues/3507 https://github.com/LadybirdBrowser/ladybird/issues/3133
2025-02-27 16:56:43 +01:00
paintable_box->set_sticky_insets(move(sticky_insets));
LibWeb: Add "position: sticky" support 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.
2024-08-24 19:20:31 +02:00
}
}
LibWeb: Measure the overflow for all scroll containers Instead of just measuring the layout viewport, we now measure overflow in every box that is a scroll container. This has the side effect of no longer creating paintables for layout boxes that didn't participate in layout. (For example, empty/anonymous boxes that were ignored by flex itemization.) Such boxes are now marked as "(not painted)" in the layout tree dumps, as they have no paintable to dump geometry from.
2023-05-29 08:53:39 +02:00
}
LibWeb: Start making our layout system "transactional" This patch adds a map of Layout::Node to FormattingState::NodeState. Instead of updating layout nodes incrementally as layout progresses through the formatting contexts, all updates are now written to the corresponding NodeState instead. At the end of layout, FormattingState::commit() is called, which transfers all the values from the NodeState objects to the Node. This will soon allow us to perform completely non-destructive layouts which don't affect the tree. Note that there are many imperfections here, and still many places where we assign to the NodeState, but later read directly from the Node instead. I'm just committing at this stage to make subsequent diffs easier to understand.
2022-02-20 15:51:24 +01:00
}
LibWeb: Make node argument to UsedValues::set_node() const No functional changes.
2025-08-27 12:37:26 +02:00
void LayoutState::UsedValues::set_node(NodeWithStyle const& node, UsedValues const* containing_block_used_values)
LibWeb: Move "has-definite-width/height" flags to UsedValues This state is less static than we originally assumed, and there are special formatting context-specific rules that say certain sizes are definite in special circumstances. To be able to support this, we move the has-definite-size flags from the layout node to the UsedValues struct instead.
2022-07-17 18:46:38 +02:00
{
m_node = &node;
LibWeb: Give UsedValues a pointer to containing block UsedValues This will allow us to skip hash lookups when traversing the containing block chain and looking at everyone's UsedValues.
2024-01-17 11:23:33 +01:00
m_containing_block_used_values = containing_block_used_values;
LibWeb: Move "has-definite-width/height" flags to UsedValues This state is less static than we originally assumed, and there are special formatting context-specific rules that say certain sizes are definite in special circumstances. To be able to support this, we move the has-definite-size flags from the layout node to the UsedValues struct instead.
2022-07-17 18:46:38 +02:00
LibWeb: Apply min/max constraints to sizes that are initially definite Also add a comment explaining how we determine initial definite sizes.
2022-10-13 14:49:08 +02:00
// NOTE: In the code below, we decide if `node` has definite width and/or height.
// This attempts to cover all the *general* cases where CSS considers sizes to be definite.
// If `node` has definite values for min/max-width or min/max-height and a definite
// preferred size in the same axis, we clamp the preferred size here as well.
//
// There are additional cases where CSS considers values to be definite. We model all of
// those by having our engine consider sizes to be definite *once they are assigned to
// the UsedValues by calling set_content_width() or set_content_height().
LibWeb: Move "has-definite-width/height" flags to UsedValues This state is less static than we originally assumed, and there are special formatting context-specific rules that say certain sizes are definite in special circumstances. To be able to support this, we move the has-definite-size flags from the layout node to the UsedValues struct instead.
2022-07-17 18:46:38 +02:00
auto const& computed_values = node.computed_values();
LibWeb: Account for box-sizing:border-box in layout-less definite sizes When we determine that a size is definite because it can be resolved now without performing layout, we also need to account for the box-sizing property. This lets us remove a hack from flex layout where box-sizing:border-box was manually undone at one point in the layout algorithm.
2023-05-02 06:51:32 +02:00
auto adjust_for_box_sizing = [&](CSSPixels unadjusted_pixels, CSS::Size const& computed_size, bool width) -> CSSPixels {
// box-sizing: content-box and/or automatic size don't require any adjustment.
if (computed_values.box_sizing() == CSS::BoxSizing::ContentBox || computed_size.is_auto())
return unadjusted_pixels;
// box-sizing: border-box requires us to subtract the relevant border and padding from the size.
CSSPixels border_and_padding;
if (width) {
LibWeb: Convert BorderData::width to CSSPixels The `clip_shrink` optimization in `paint_background()` now also correctly uses DevicePixels, instead of reducing a DevicePixel rect by a CSSPixels amount.
2023-07-30 15:54:57 +01:00
border_and_padding = computed_values.border_left().width
LibWeb: Make LengthBox hold LengthPercentageOrAuto Not every user of this requires an `auto` state, but most do. This has quite a big diff but most of that is mechanical: LengthPercentageOrAuto has `resolved_or_auto()` instead of `resolved()`, and `to_px_or_zero()` instead of `to_px()`, to make their output clearer.
2025-09-01 12:51:52 +01:00
+ computed_values.padding().left().to_px_or_zero(*m_node, containing_block_used_values->content_width())
LibWeb: Convert BorderData::width to CSSPixels The `clip_shrink` optimization in `paint_background()` now also correctly uses DevicePixels, instead of reducing a DevicePixel rect by a CSSPixels amount.
2023-07-30 15:54:57 +01:00
+ computed_values.border_right().width
LibWeb: Make LengthBox hold LengthPercentageOrAuto Not every user of this requires an `auto` state, but most do. This has quite a big diff but most of that is mechanical: LengthPercentageOrAuto has `resolved_or_auto()` instead of `resolved()`, and `to_px_or_zero()` instead of `to_px()`, to make their output clearer.
2025-09-01 12:51:52 +01:00
+ computed_values.padding().right().to_px_or_zero(*m_node, containing_block_used_values->content_width());
LibWeb: Account for box-sizing:border-box in layout-less definite sizes When we determine that a size is definite because it can be resolved now without performing layout, we also need to account for the box-sizing property. This lets us remove a hack from flex layout where box-sizing:border-box was manually undone at one point in the layout algorithm.
2023-05-02 06:51:32 +02:00
} else {
LibWeb: Convert BorderData::width to CSSPixels The `clip_shrink` optimization in `paint_background()` now also correctly uses DevicePixels, instead of reducing a DevicePixel rect by a CSSPixels amount.
2023-07-30 15:54:57 +01:00
border_and_padding = computed_values.border_top().width
LibWeb: Make LengthBox hold LengthPercentageOrAuto Not every user of this requires an `auto` state, but most do. This has quite a big diff but most of that is mechanical: LengthPercentageOrAuto has `resolved_or_auto()` instead of `resolved()`, and `to_px_or_zero()` instead of `to_px()`, to make their output clearer.
2025-09-01 12:51:52 +01:00
+ computed_values.padding().top().to_px_or_zero(*m_node, containing_block_used_values->content_width())
LibWeb: Convert BorderData::width to CSSPixels The `clip_shrink` optimization in `paint_background()` now also correctly uses DevicePixels, instead of reducing a DevicePixel rect by a CSSPixels amount.
2023-07-30 15:54:57 +01:00
+ computed_values.border_bottom().width
LibWeb: Make LengthBox hold LengthPercentageOrAuto Not every user of this requires an `auto` state, but most do. This has quite a big diff but most of that is mechanical: LengthPercentageOrAuto has `resolved_or_auto()` instead of `resolved()`, and `to_px_or_zero()` instead of `to_px()`, to make their output clearer.
2025-09-01 12:51:52 +01:00
+ computed_values.padding().bottom().to_px_or_zero(*m_node, containing_block_used_values->content_width());
LibWeb: Account for box-sizing:border-box in layout-less definite sizes When we determine that a size is definite because it can be resolved now without performing layout, we also need to account for the box-sizing property. This lets us remove a hack from flex layout where box-sizing:border-box was manually undone at one point in the layout algorithm.
2023-05-02 06:51:32 +02:00
}
return unadjusted_pixels - border_and_padding;
};
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
auto is_definite_size = [&](CSS::Size const& size, CSSPixels& resolved_definite_size, bool width) {
LibWeb: Move "has-definite-width/height" flags to UsedValues This state is less static than we originally assumed, and there are special formatting context-specific rules that say certain sizes are definite in special circumstances. To be able to support this, we move the has-definite-size flags from the layout node to the UsedValues struct instead.
2022-07-17 18:46:38 +02:00
// A size that can be determined without performing layout; that is,
// a <length>,
// a measure of text (without consideration of line-wrapping),
// a size of the initial containing block,
// or a <percentage> or other formula (such as the “stretch-fit” sizing of non-replaced blocks [CSS2]) that is resolved solely against definite sizes.
auto containing_block_has_definite_size = containing_block_used_values ? (width ? containing_block_used_values->has_definite_width() : containing_block_used_values->has_definite_height()) : false;
if (size.is_auto()) {
// NOTE: The width of a non-flex-item block is considered definite if it's auto and the containing block has definite width.
LibWeb: Reorganize layout algorithms around available space This is a big and messy change, and here's the gist: - AvaliableSpace is now 2x AvailableSize (width and height) - Layout algorithms are redesigned around the idea of available space - When doing layout across nested formatting contexts, the parent context tells the child context how much space is available for the child's root box in both axes. - "Available space" replaces "containing block width" in most places. - The width and height in a box's UsedValues are considered to be definite after they're assigned to. Marking something as having definite size is no longer a separate step, This probably introduces various regressions, but the big win here is that our layout system now works with available space, just like the specs are written. Fixing issues will be much easier going forward, since you don't need to do nearly as much conversion from "spec logic" to "LibWeb logic" as you previously did.
2022-09-27 15:29:17 +02:00
if (width
LibWeb: Floating boxes with width:auto don't have definite width Since layout is required in order to determine the width of such boxes, they should not be marked as having definite width initially.
2022-10-07 13:07:40 +02:00
&& !node.is_floating()
LibWeb: Do not treat size of abspos items as definite This fixes the issue when size of abspos items is considered to be resolvable without performing layout which is not correct in the scenarious when top/right/bottom/left properties are not auto.
2023-06-22 18:02:04 +03:00
&& !node.is_absolutely_positioned()
LibWeb: Use Layout::Node::display() everywhere
2022-10-06 16:02:53 +02:00
&& node.display().is_block_outside()
LibWeb: Reorganize layout algorithms around available space This is a big and messy change, and here's the gist: - AvaliableSpace is now 2x AvailableSize (width and height) - Layout algorithms are redesigned around the idea of available space - When doing layout across nested formatting contexts, the parent context tells the child context how much space is available for the child's root box in both axes. - "Available space" replaces "containing block width" in most places. - The width and height in a box's UsedValues are considered to be definite after they're assigned to. Marking something as having definite size is no longer a separate step, This probably introduces various regressions, but the big win here is that our layout system now works with available space, just like the specs are written. Fixing issues will be much easier going forward, since you don't need to do nearly as much conversion from "spec logic" to "LibWeb logic" as you previously did.
2022-09-27 15:29:17 +02:00
&& node.parent()
&& !node.parent()->is_floating()
LibWeb: Use Layout::Node::display() everywhere
2022-10-06 16:02:53 +02:00
&& (node.parent()->display().is_flow_root_inside()
|| node.parent()->display().is_flow_inside())) {
LibWeb: Resolve definite sizes when instantiating UsedValues When we decide that a box has definite width or height based on its containing block's corresponding size, we'll want to resolve the current box's size as well. Otherwise anyone querying the size on this box will get the bogus message of "yes, this definite, and its value is zero."
2022-07-19 13:46:27 +02:00
if (containing_block_has_definite_size) {
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
CSSPixels available_width = containing_block_used_values->content_width();
LibWeb: Clamp layout content sizes to a max value instead of crashing We've historically asserted that no "saturated" size values end up as final metrics for boxes in layout. This always had a chance of producing false positives, since you can trivially create extremely large boxes with CSS. The reason we had those assertions was to catch bugs in our own engine code where we'd incorrectly end up with non-finite values in layout algorithms. At this point, we've found and fixed all known bugs of that nature, and what remains are a bunch of false positives on pages that create very large scrollable areas, iframes etc. So, let's change it! We now clamp content width and height of boxes to 17895700 pixels, apparently the same cap as Firefox uses. There's also the issue of calc() being able to produce non-finite values. Note that we don't clamp the result of calc() directly, but instead just clamp values when assigning them to content sizes. Fixes #645. Fixes #1236. Fixes #1249. Fixes #1908. Fixes #3057.
2025-02-05 14:13:33 +01:00
resolved_definite_size = clamp_to_max_dimension_value(
available_width
LibWeb: Reorganize layout algorithms around available space This is a big and messy change, and here's the gist: - AvaliableSpace is now 2x AvailableSize (width and height) - Layout algorithms are redesigned around the idea of available space - When doing layout across nested formatting contexts, the parent context tells the child context how much space is available for the child's root box in both axes. - "Available space" replaces "containing block width" in most places. - The width and height in a box's UsedValues are considered to be definite after they're assigned to. Marking something as having definite size is no longer a separate step, This probably introduces various regressions, but the big win here is that our layout system now works with available space, just like the specs are written. Fixing issues will be much easier going forward, since you don't need to do nearly as much conversion from "spec logic" to "LibWeb logic" as you previously did.
2022-09-27 15:29:17 +02:00
- margin_left
- margin_right
- padding_left
- padding_right
- border_left
LibWeb: Clamp layout content sizes to a max value instead of crashing We've historically asserted that no "saturated" size values end up as final metrics for boxes in layout. This always had a chance of producing false positives, since you can trivially create extremely large boxes with CSS. The reason we had those assertions was to catch bugs in our own engine code where we'd incorrectly end up with non-finite values in layout algorithms. At this point, we've found and fixed all known bugs of that nature, and what remains are a bunch of false positives on pages that create very large scrollable areas, iframes etc. So, let's change it! We now clamp content width and height of boxes to 17895700 pixels, apparently the same cap as Firefox uses. There's also the issue of calc() being able to produce non-finite values. Note that we don't clamp the result of calc() directly, but instead just clamp values when assigning them to content sizes. Fixes #645. Fixes #1236. Fixes #1249. Fixes #1908. Fixes #3057.
2025-02-05 14:13:33 +01:00
- border_right);
LibWeb: Resolve definite sizes when instantiating UsedValues When we decide that a box has definite width or height based on its containing block's corresponding size, we'll want to resolve the current box's size as well. Otherwise anyone querying the size on this box will get the bogus message of "yes, this definite, and its value is zero."
2022-07-19 13:46:27 +02:00
return true;
}
return false;
}
LibWeb: Move "has-definite-width/height" flags to UsedValues This state is less static than we originally assumed, and there are special formatting context-specific rules that say certain sizes are definite in special circumstances. To be able to support this, we move the has-definite-size flags from the layout node to the UsedValues struct instead.
2022-07-17 18:46:38 +02:00
return false;
}
LibWeb: Remove CalculatedStyleValue from Length
2023-03-30 15:46:05 +01:00
if (size.is_calculated()) {
LibWeb/CSS: Wrap calc()-resolution data in a struct Initially I added this to the existing CalculationContext, but in reality, we have some data at parse-time and different data at resolve-time, so it made more sense to keep those separate. Instead of needing a variety of methods for resolving a Foo, depending on whether we have a Layout::Node available, or a percentage basis, or a length resolution context... put those in a CalculationResolutionContext, and just pass that one thing to these methods. This also removes the need for separate resolve_*_percentage() methods, because we can just pass the percentage basis in to the regular resolve_foo() method. This also corrects the issue that *any* calculation may need to resolve lengths, but we previously only passed a length resolution context to specific types in some situations. Now, they can all have one available, though it's up to the caller to provide it.
2025-01-22 16:05:32 +00:00
CSS::CalculationResolutionContext context {
.length_resolution_context = CSS::Length::ResolutionContext::for_layout_node(node),
};
LibWeb: Remove CalculatedStyleValue from Length
2023-03-30 15:46:05 +01:00
if (size.calculated().contains_percentage()) {
LibWeb: Mark percentage heights as initially definite when appropriate Percentage heights are now considered definite when their containing block has a definite height. This makes profile pictures have geometry on Twitter. (We still don't load the images themselves though.)
2022-10-13 11:16:54 +02:00
if (!containing_block_has_definite_size)
return false;
LibWeb: Add `Length::resolved()` overload for CSSPixels Since we always pass the px value as an argument to resolved(), we can pass it directly as CSSPixels instead of wrapping it in Length. This approach allows us to avoid converting to a double, resulting in fewer precision issues.
2023-08-29 18:57:09 +02:00
auto containing_block_size_as_length = width ? containing_block_used_values->content_width() : containing_block_used_values->content_height();
LibWeb/CSS: Wrap calc()-resolution data in a struct Initially I added this to the existing CalculationContext, but in reality, we have some data at parse-time and different data at resolve-time, so it made more sense to keep those separate. Instead of needing a variety of methods for resolving a Foo, depending on whether we have a Layout::Node available, or a percentage basis, or a length resolution context... put those in a CalculationResolutionContext, and just pass that one thing to these methods. This also removes the need for separate resolve_*_percentage() methods, because we can just pass the percentage basis in to the regular resolve_foo() method. This also corrects the issue that *any* calculation may need to resolve lengths, but we previously only passed a length resolution context to specific types in some situations. Now, they can all have one available, though it's up to the caller to provide it.
2025-01-22 16:05:32 +00:00
context.percentage_basis = CSS::Length::make_px(containing_block_size_as_length);
LibWeb: Reorganize layout algorithms around available space This is a big and messy change, and here's the gist: - AvaliableSpace is now 2x AvailableSize (width and height) - Layout algorithms are redesigned around the idea of available space - When doing layout across nested formatting contexts, the parent context tells the child context how much space is available for the child's root box in both axes. - "Available space" replaces "containing block width" in most places. - The width and height in a box's UsedValues are considered to be definite after they're assigned to. Marking something as having definite size is no longer a separate step, This probably introduces various regressions, but the big win here is that our layout system now works with available space, just like the specs are written. Fixing issues will be much easier going forward, since you don't need to do nearly as much conversion from "spec logic" to "LibWeb logic" as you previously did.
2022-09-27 15:29:17 +02:00
}
LibWeb/CSS: Replace resolve_length_deprecated() with resolve_length()
2025-09-24 14:33:18 +01:00
resolved_definite_size = clamp_to_max_dimension_value(adjust_for_box_sizing(size.calculated().resolve_length(context)->to_px(node), size, width));
LibWeb: Move "has-definite-width/height" flags to UsedValues This state is less static than we originally assumed, and there are special formatting context-specific rules that say certain sizes are definite in special circumstances. To be able to support this, we move the has-definite-size flags from the layout node to the UsedValues struct instead.
2022-07-17 18:46:38 +02:00
return true;
LibWeb: Resolve definite sizes when instantiating UsedValues When we decide that a box has definite width or height based on its containing block's corresponding size, we'll want to resolve the current box's size as well. Otherwise anyone querying the size on this box will get the bogus message of "yes, this definite, and its value is zero."
2022-07-19 13:46:27 +02:00
}
LibWeb: Reorganize layout algorithms around available space This is a big and messy change, and here's the gist: - AvaliableSpace is now 2x AvailableSize (width and height) - Layout algorithms are redesigned around the idea of available space - When doing layout across nested formatting contexts, the parent context tells the child context how much space is available for the child's root box in both axes. - "Available space" replaces "containing block width" in most places. - The width and height in a box's UsedValues are considered to be definite after they're assigned to. Marking something as having definite size is no longer a separate step, This probably introduces various regressions, but the big win here is that our layout system now works with available space, just like the specs are written. Fixing issues will be much easier going forward, since you don't need to do nearly as much conversion from "spec logic" to "LibWeb logic" as you previously did.
2022-09-27 15:29:17 +02:00
if (size.is_length()) {
LibWeb: Remove CalculatedStyleValue from Length
2023-03-30 15:46:05 +01:00
VERIFY(!size.is_auto()); // This should have been covered by the Size::is_auto() branch above.
LibWeb: Clamp layout content sizes to a max value instead of crashing We've historically asserted that no "saturated" size values end up as final metrics for boxes in layout. This always had a chance of producing false positives, since you can trivially create extremely large boxes with CSS. The reason we had those assertions was to catch bugs in our own engine code where we'd incorrectly end up with non-finite values in layout algorithms. At this point, we've found and fixed all known bugs of that nature, and what remains are a bunch of false positives on pages that create very large scrollable areas, iframes etc. So, let's change it! We now clamp content width and height of boxes to 17895700 pixels, apparently the same cap as Firefox uses. There's also the issue of calc() being able to produce non-finite values. Note that we don't clamp the result of calc() directly, but instead just clamp values when assigning them to content sizes. Fixes #645. Fixes #1236. Fixes #1249. Fixes #1908. Fixes #3057.
2025-02-05 14:13:33 +01:00
resolved_definite_size = clamp_to_max_dimension_value(adjust_for_box_sizing(size.length().to_px(node), size, width));
LibWeb: Reorganize layout algorithms around available space This is a big and messy change, and here's the gist: - AvaliableSpace is now 2x AvailableSize (width and height) - Layout algorithms are redesigned around the idea of available space - When doing layout across nested formatting contexts, the parent context tells the child context how much space is available for the child's root box in both axes. - "Available space" replaces "containing block width" in most places. - The width and height in a box's UsedValues are considered to be definite after they're assigned to. Marking something as having definite size is no longer a separate step, This probably introduces various regressions, but the big win here is that our layout system now works with available space, just like the specs are written. Fixing issues will be much easier going forward, since you don't need to do nearly as much conversion from "spec logic" to "LibWeb logic" as you previously did.
2022-09-27 15:29:17 +02:00
return true;
}
LibWeb: Resolve definite sizes when instantiating UsedValues When we decide that a box has definite width or height based on its containing block's corresponding size, we'll want to resolve the current box's size as well. Otherwise anyone querying the size on this box will get the bogus message of "yes, this definite, and its value is zero."
2022-07-19 13:46:27 +02:00
if (size.is_percentage()) {
if (containing_block_has_definite_size) {
auto containing_block_size = width ? containing_block_used_values->content_width() : containing_block_used_values->content_height();
LibWeb: Clamp layout content sizes to a max value instead of crashing We've historically asserted that no "saturated" size values end up as final metrics for boxes in layout. This always had a chance of producing false positives, since you can trivially create extremely large boxes with CSS. The reason we had those assertions was to catch bugs in our own engine code where we'd incorrectly end up with non-finite values in layout algorithms. At this point, we've found and fixed all known bugs of that nature, and what remains are a bunch of false positives on pages that create very large scrollable areas, iframes etc. So, let's change it! We now clamp content width and height of boxes to 17895700 pixels, apparently the same cap as Firefox uses. There's also the issue of calc() being able to produce non-finite values. Note that we don't clamp the result of calc() directly, but instead just clamp values when assigning them to content sizes. Fixes #645. Fixes #1236. Fixes #1249. Fixes #1908. Fixes #3057.
2025-02-05 14:13:33 +01:00
resolved_definite_size = clamp_to_max_dimension_value(adjust_for_box_sizing(containing_block_size.scaled(size.percentage().as_fraction()), size, width));
LibWeb: Resolve definite sizes when instantiating UsedValues When we decide that a box has definite width or height based on its containing block's corresponding size, we'll want to resolve the current box's size as well. Otherwise anyone querying the size on this box will get the bogus message of "yes, this definite, and its value is zero."
2022-07-19 13:46:27 +02:00
return true;
}
return false;
}
LibWeb: Move "has-definite-width/height" flags to UsedValues This state is less static than we originally assumed, and there are special formatting context-specific rules that say certain sizes are definite in special circumstances. To be able to support this, we move the has-definite-size flags from the layout node to the UsedValues struct instead.
2022-07-17 18:46:38 +02:00
return false;
};
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
CSSPixels min_width = 0;
LibWeb: Apply min/max constraints to sizes that are initially definite Also add a comment explaining how we determine initial definite sizes.
2022-10-13 14:49:08 +02:00
bool has_definite_min_width = is_definite_size(computed_values.min_width(), min_width, true);
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
CSSPixels max_width = 0;
LibWeb: Apply min/max constraints to sizes that are initially definite Also add a comment explaining how we determine initial definite sizes.
2022-10-13 14:49:08 +02:00
bool has_definite_max_width = is_definite_size(computed_values.max_width(), max_width, true);
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
CSSPixels min_height = 0;
LibWeb: Apply min/max constraints to sizes that are initially definite Also add a comment explaining how we determine initial definite sizes.
2022-10-13 14:49:08 +02:00
bool has_definite_min_height = is_definite_size(computed_values.min_height(), min_height, false);
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
CSSPixels max_height = 0;
LibWeb: Apply min/max constraints to sizes that are initially definite Also add a comment explaining how we determine initial definite sizes.
2022-10-13 14:49:08 +02:00
bool has_definite_max_height = is_definite_size(computed_values.max_height(), max_height, false);
LibWeb: Resolve definite sizes when instantiating UsedValues When we decide that a box has definite width or height based on its containing block's corresponding size, we'll want to resolve the current box's size as well. Otherwise anyone querying the size on this box will get the bogus message of "yes, this definite, and its value is zero."
2022-07-19 13:46:27 +02:00
m_has_definite_width = is_definite_size(computed_values.width(), m_content_width, true);
m_has_definite_height = is_definite_size(computed_values.height(), m_content_height, false);
LibWeb: Apply min/max constraints to sizes that are initially definite Also add a comment explaining how we determine initial definite sizes.
2022-10-13 14:49:08 +02:00
if (m_has_definite_width) {
if (has_definite_min_width)
LibWeb: Clamp layout content sizes to a max value instead of crashing We've historically asserted that no "saturated" size values end up as final metrics for boxes in layout. This always had a chance of producing false positives, since you can trivially create extremely large boxes with CSS. The reason we had those assertions was to catch bugs in our own engine code where we'd incorrectly end up with non-finite values in layout algorithms. At this point, we've found and fixed all known bugs of that nature, and what remains are a bunch of false positives on pages that create very large scrollable areas, iframes etc. So, let's change it! We now clamp content width and height of boxes to 17895700 pixels, apparently the same cap as Firefox uses. There's also the issue of calc() being able to produce non-finite values. Note that we don't clamp the result of calc() directly, but instead just clamp values when assigning them to content sizes. Fixes #645. Fixes #1236. Fixes #1249. Fixes #1908. Fixes #3057.
2025-02-05 14:13:33 +01:00
m_content_width = clamp_to_max_dimension_value(max(min_width, m_content_width));
LibWeb: Apply min/max constraints to sizes that are initially definite Also add a comment explaining how we determine initial definite sizes.
2022-10-13 14:49:08 +02:00
if (has_definite_max_width)
LibWeb: Clamp layout content sizes to a max value instead of crashing We've historically asserted that no "saturated" size values end up as final metrics for boxes in layout. This always had a chance of producing false positives, since you can trivially create extremely large boxes with CSS. The reason we had those assertions was to catch bugs in our own engine code where we'd incorrectly end up with non-finite values in layout algorithms. At this point, we've found and fixed all known bugs of that nature, and what remains are a bunch of false positives on pages that create very large scrollable areas, iframes etc. So, let's change it! We now clamp content width and height of boxes to 17895700 pixels, apparently the same cap as Firefox uses. There's also the issue of calc() being able to produce non-finite values. Note that we don't clamp the result of calc() directly, but instead just clamp values when assigning them to content sizes. Fixes #645. Fixes #1236. Fixes #1249. Fixes #1908. Fixes #3057.
2025-02-05 14:13:33 +01:00
m_content_width = clamp_to_max_dimension_value(min(max_width, m_content_width));
LibWeb: Apply min/max constraints to sizes that are initially definite Also add a comment explaining how we determine initial definite sizes.
2022-10-13 14:49:08 +02:00
}
if (m_has_definite_height) {
if (has_definite_min_height)
LibWeb: Clamp layout content sizes to a max value instead of crashing We've historically asserted that no "saturated" size values end up as final metrics for boxes in layout. This always had a chance of producing false positives, since you can trivially create extremely large boxes with CSS. The reason we had those assertions was to catch bugs in our own engine code where we'd incorrectly end up with non-finite values in layout algorithms. At this point, we've found and fixed all known bugs of that nature, and what remains are a bunch of false positives on pages that create very large scrollable areas, iframes etc. So, let's change it! We now clamp content width and height of boxes to 17895700 pixels, apparently the same cap as Firefox uses. There's also the issue of calc() being able to produce non-finite values. Note that we don't clamp the result of calc() directly, but instead just clamp values when assigning them to content sizes. Fixes #645. Fixes #1236. Fixes #1249. Fixes #1908. Fixes #3057.
2025-02-05 14:13:33 +01:00
m_content_height = clamp_to_max_dimension_value(max(min_height, m_content_height));
LibWeb: Apply min/max constraints to sizes that are initially definite Also add a comment explaining how we determine initial definite sizes.
2022-10-13 14:49:08 +02:00
if (has_definite_max_height)
LibWeb: Clamp layout content sizes to a max value instead of crashing We've historically asserted that no "saturated" size values end up as final metrics for boxes in layout. This always had a chance of producing false positives, since you can trivially create extremely large boxes with CSS. The reason we had those assertions was to catch bugs in our own engine code where we'd incorrectly end up with non-finite values in layout algorithms. At this point, we've found and fixed all known bugs of that nature, and what remains are a bunch of false positives on pages that create very large scrollable areas, iframes etc. So, let's change it! We now clamp content width and height of boxes to 17895700 pixels, apparently the same cap as Firefox uses. There's also the issue of calc() being able to produce non-finite values. Note that we don't clamp the result of calc() directly, but instead just clamp values when assigning them to content sizes. Fixes #645. Fixes #1236. Fixes #1249. Fixes #1908. Fixes #3057.
2025-02-05 14:13:33 +01:00
m_content_height = clamp_to_max_dimension_value(min(max_height, m_content_height));
LibWeb: Apply min/max constraints to sizes that are initially definite Also add a comment explaining how we determine initial definite sizes.
2022-10-13 14:49:08 +02:00
}
LibWeb: Move "has-definite-width/height" flags to UsedValues This state is less static than we originally assumed, and there are special formatting context-specific rules that say certain sizes are definite in special circumstances. To be able to support this, we move the has-definite-size flags from the layout node to the UsedValues struct instead.
2022-07-17 18:46:38 +02:00
}
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
void LayoutState::UsedValues::set_content_width(CSSPixels width)
LibWeb: Add accessors for UsedValues::computed_{width,height} This is preparation for doing some more work when assigning to these values.
2022-07-17 17:59:02 +02:00
{
LibWeb: Add FIXME whining to debug log if layout produces negative sizes Negative width/height sizes are not allowed in CSS, so if our layout algorithm resolves something to a negative size, we have boogs. Instead of crashing or rendering something very wrong, we now clamp the values to 0 and whine on the debug log so that someone can go and figure out how we got the negative values in the first place. :^)
2023-03-25 17:33:22 +01:00
if (width < 0) {
LibWeb: Fix mistype in `LayoutState`
2023-03-26 22:25:53 +11:00
// Negative widths are not allowed in CSS. We have a bug somewhere! Clamp to 0 to avoid doing too much damage.
LibWeb: Put debug spam about negative content sizes behind a flag We already clamp these values to zero, so it's actually pretty harmless when this happens. If someone wants to investigate these issues deeper and see if they can be fixed earlier in the layout pipeline, they can enable the spam locally.
2023-05-31 11:47:26 +02:00
dbgln_if(LIBWEB_CSS_DEBUG, "FIXME: Layout calculated a negative width for {}: {}", m_node->debug_description(), width);
LibWeb: Add FIXME whining to debug log if layout produces negative sizes Negative width/height sizes are not allowed in CSS, so if our layout algorithm resolves something to a negative size, we have boogs. Instead of crashing or rendering something very wrong, we now clamp the values to 0 and whine on the debug log so that someone can go and figure out how we got the negative values in the first place. :^)
2023-03-25 17:33:22 +01:00
width = 0;
}
LibWeb: Clamp layout content sizes to a max value instead of crashing We've historically asserted that no "saturated" size values end up as final metrics for boxes in layout. This always had a chance of producing false positives, since you can trivially create extremely large boxes with CSS. The reason we had those assertions was to catch bugs in our own engine code where we'd incorrectly end up with non-finite values in layout algorithms. At this point, we've found and fixed all known bugs of that nature, and what remains are a bunch of false positives on pages that create very large scrollable areas, iframes etc. So, let's change it! We now clamp content width and height of boxes to 17895700 pixels, apparently the same cap as Firefox uses. There's also the issue of calc() being able to produce non-finite values. Note that we don't clamp the result of calc() directly, but instead just clamp values when assigning them to content sizes. Fixes #645. Fixes #1236. Fixes #1249. Fixes #1908. Fixes #3057.
2025-02-05 14:13:33 +01:00
m_content_width = clamp_to_max_dimension_value(width);
LibWeb: Add FIXME about definiteness to UsedValues::set_content_width() Fixing this function will be quite an undertaking since a *lot* of code relies on set_content_width() implicitly flipping the definiteness of the width. It is wrong though, so we do need to fix it eventually.
2024-02-21 15:27:37 +01:00
// FIXME: We should not do this! Definiteness of widths should be determined early,
// and not changed later (except for some special cases in flex layout..)
LibWeb: Reorganize layout algorithms around available space This is a big and messy change, and here's the gist: - AvaliableSpace is now 2x AvailableSize (width and height) - Layout algorithms are redesigned around the idea of available space - When doing layout across nested formatting contexts, the parent context tells the child context how much space is available for the child's root box in both axes. - "Available space" replaces "containing block width" in most places. - The width and height in a box's UsedValues are considered to be definite after they're assigned to. Marking something as having definite size is no longer a separate step, This probably introduces various regressions, but the big win here is that our layout system now works with available space, just like the specs are written. Fixing issues will be much easier going forward, since you don't need to do nearly as much conversion from "spec logic" to "LibWeb logic" as you previously did.
2022-09-27 15:29:17 +02:00
m_has_definite_width = true;
LibWeb: Add accessors for UsedValues::computed_{width,height} This is preparation for doing some more work when assigning to these values.
2022-07-17 17:59:02 +02:00
}
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
void LayoutState::UsedValues::set_content_height(CSSPixels height)
LibWeb: Add accessors for UsedValues::computed_{width,height} This is preparation for doing some more work when assigning to these values.
2022-07-17 17:59:02 +02:00
{
LibWeb: Add FIXME whining to debug log if layout produces negative sizes Negative width/height sizes are not allowed in CSS, so if our layout algorithm resolves something to a negative size, we have boogs. Instead of crashing or rendering something very wrong, we now clamp the values to 0 and whine on the debug log so that someone can go and figure out how we got the negative values in the first place. :^)
2023-03-25 17:33:22 +01:00
if (height < 0) {
// Negative heights are not allowed in CSS. We have a bug somewhere! Clamp to 0 to avoid doing too much damage.
LibWeb: Put debug spam about negative content sizes behind a flag We already clamp these values to zero, so it's actually pretty harmless when this happens. If someone wants to investigate these issues deeper and see if they can be fixed earlier in the layout pipeline, they can enable the spam locally.
2023-05-31 11:47:26 +02:00
dbgln_if(LIBWEB_CSS_DEBUG, "FIXME: Layout calculated a negative height for {}: {}", m_node->debug_description(), height);
LibWeb: Add FIXME whining to debug log if layout produces negative sizes Negative width/height sizes are not allowed in CSS, so if our layout algorithm resolves something to a negative size, we have boogs. Instead of crashing or rendering something very wrong, we now clamp the values to 0 and whine on the debug log so that someone can go and figure out how we got the negative values in the first place. :^)
2023-03-25 17:33:22 +01:00
height = 0;
}
LibWeb: Clamp layout content sizes to a max value instead of crashing We've historically asserted that no "saturated" size values end up as final metrics for boxes in layout. This always had a chance of producing false positives, since you can trivially create extremely large boxes with CSS. The reason we had those assertions was to catch bugs in our own engine code where we'd incorrectly end up with non-finite values in layout algorithms. At this point, we've found and fixed all known bugs of that nature, and what remains are a bunch of false positives on pages that create very large scrollable areas, iframes etc. So, let's change it! We now clamp content width and height of boxes to 17895700 pixels, apparently the same cap as Firefox uses. There's also the issue of calc() being able to produce non-finite values. Note that we don't clamp the result of calc() directly, but instead just clamp values when assigning them to content sizes. Fixes #645. Fixes #1236. Fixes #1249. Fixes #1908. Fixes #3057.
2025-02-05 14:13:33 +01:00
m_content_height = clamp_to_max_dimension_value(height);
LibWeb: Add accessors for UsedValues::computed_{width,height} This is preparation for doing some more work when assigning to these values.
2022-07-17 17:59:02 +02:00
}
LibWeb: Reorganize layout algorithms around available space This is a big and messy change, and here's the gist: - AvaliableSpace is now 2x AvailableSize (width and height) - Layout algorithms are redesigned around the idea of available space - When doing layout across nested formatting contexts, the parent context tells the child context how much space is available for the child's root box in both axes. - "Available space" replaces "containing block width" in most places. - The width and height in a box's UsedValues are considered to be definite after they're assigned to. Marking something as having definite size is no longer a separate step, This probably introduces various regressions, but the big win here is that our layout system now works with available space, just like the specs are written. Fixing issues will be much easier going forward, since you don't need to do nearly as much conversion from "spec logic" to "LibWeb logic" as you previously did.
2022-09-27 15:29:17 +02:00
AvailableSize LayoutState::UsedValues::available_width_inside() const
{
if (width_constraint == SizeConstraint::MinContent)
return AvailableSize::make_min_content();
if (width_constraint == SizeConstraint::MaxContent)
return AvailableSize::make_max_content();
if (has_definite_width())
return AvailableSize::make_definite(m_content_width);
return AvailableSize::make_indefinite();
}
AvailableSize LayoutState::UsedValues::available_height_inside() const
{
if (height_constraint == SizeConstraint::MinContent)
return AvailableSize::make_min_content();
if (height_constraint == SizeConstraint::MaxContent)
return AvailableSize::make_max_content();
if (has_definite_height())
return AvailableSize::make_definite(m_content_height);
return AvailableSize::make_indefinite();
}
AvailableSpace LayoutState::UsedValues::available_inner_space_or_constraints_from(AvailableSpace const& outer_space) const
{
auto inner_width = available_width_inside();
auto inner_height = available_height_inside();
if (inner_width.is_indefinite() && outer_space.width.is_intrinsic_sizing_constraint())
inner_width = outer_space.width;
if (inner_height.is_indefinite() && outer_space.height.is_intrinsic_sizing_constraint())
inner_height = outer_space.height;
return AvailableSpace(inner_width, inner_height);
}
LibWeb: Make box content sizes indefinite before intrinsic sizing When calculating the intrinsic width of a box, we now make its content width & height indefinite before entering the intrinsic sizing layout. This ensures that any geometry assigned to the box by its parent formatting context is ignored. For intrinsic heights, we only make the content height indefinite. This is because used content width is a valid (but optional) input to intrinsic height calculation.
2023-03-27 14:12:05 +02:00
void LayoutState::UsedValues::set_indefinite_content_width()
{
m_has_definite_width = false;
}
void LayoutState::UsedValues::set_indefinite_content_height()
{
m_has_definite_height = false;
}
Meta: Enforce newlines around namespaces This has come up several times during code review, so let's just enforce it using a new clang-format 20 option.
2025-05-13 07:06:33 -04:00
LibWeb: Start making our layout system "transactional" This patch adds a map of Layout::Node to FormattingState::NodeState. Instead of updating layout nodes incrementally as layout progresses through the formatting contexts, all updates are now written to the corresponding NodeState instead. At the end of layout, FormattingState::commit() is called, which transfers all the values from the NodeState objects to the Node. This will soon allow us to perform completely non-destructive layouts which don't affect the tree. Note that there are many imperfections here, and still many places where we assign to the NodeState, but later read directly from the Node instead. I'm just committing at this stage to make subsequent diffs easier to understand.
2022-02-20 15:51:24 +01:00
}
Reference in a new issue Copy permalink