LibWeb: Correctly lay out block elements inside inline elements #3276

gmta · 2025-01-16T15:35:53Z

The contents of inline elements containing a block element were incorrectly ordered, e.g.

<b>foo<div>bar</div>baz</b>

...did not render the <div> as being in between the foo and baz fragments.

Before	After

Excerpt from Web::Layout::TreeBuilder:

Block nodes inside inline nodes are allowed, but to maintain the invariant that either all layout children are
inline or non-inline, we need to rearrange the tree a bit. All inline ancestors up to the node we've inserted are
wrapped in an anonymous block, which is inserted into the nearest non-inline ancestor. We then recreate the inline
ancestors in another anonymous block inserted after the node so we can continue adding children.

Effectively, we try to turn this:

InlineNode 1
  TextNode 1
  InlineNode N
    TextNode N
    BlockContainer (node)

Into this:

BlockContainer (anonymous "before")
  InlineNode 1
    TextNode 1
    InlineNode N
      TextNode N
BlockContainer (anonymous "middle") continuation
  BlockContainer (node)
BlockContainer (anonymous "after")
  InlineNode 1 continuation
    InlineNode N

To be able to reconstruct their relation after restructuring, layout nodes keep track of their continuation. The
top-most inline node of the "after" wrapper points to the "middle" wrapper, which points to the top-most inline node
of the "before" wrapper. All other inline nodes in the "after" wrapper point to their counterparts in the "before"
wrapper, to make it easier to create the right paintables since a DOM::Node only has a single Layout::Node.

Appending then continues in the "after" tree. If a new block node is then inserted, we can reuse the "middle" wrapper
if no inline siblings exist for node or its ancestors, and leave the existing "after" wrapper alone. Otherwise, we
create new wrappers and extend the continuation chain.

Inspired by: https://webkit.org/blog/115/webcore-rendering-ii-blocks-and-inlines/

kalenikaliaksandr

have you considered solving the problem on paintable tree level? I suppose webkit has to use continuations on layout tree because they do not have paintable tree concept, while we do and support 1:N relationship between layout and paintable nodes.

Libraries/LibWeb/Layout/Node.h

gmta · 2025-01-17T12:19:56Z

@kalenikaliaksandr @awesomekling I've rearranged some things:

Determining the united border/padding/margin/content rects is now the responsibility of PaintableBox again.
The continuation chain is still only part of the layout tree however; it's not clear to me if we're always going to have paintables for parts of split-up inline elements that might not be visible (e.g. in <b><div>foo</div>bar</b>) and if so, how we're going to reliably link up the right paintables during creation of the painting tree. I've left a FIXME in PaintableBox to this end.
More DOM methods were updated and I've added a test for offsetTop/Left/Width/Height.

kalenikaliaksandr

could we add a test for hit-testing just so we can be sure it works as expected when it comes to continuations?

gmta · 2025-01-17T14:11:04Z

could we add a test for hit-testing just so we can be sure it works as expected when it comes to continuations?

Absolutely, in fact, I'm also working on a bugfix for something depending on this that involves hit-testing. I'll tack on the commit to this PR.

awesomekling · 2025-01-18T09:16:22Z

Ran into a simple case that doesn't work correctly:

Well <span> hello <div>friends

gmta · 2025-01-18T09:21:48Z

Ran into a simple case that doesn't work correctly:
Well <span> hello <div>friends

Well that's embarrassing! I'll take a look

awesomekling · 2025-01-18T09:41:46Z

And here's a basic dynamic case that doesn't work -- looks like we don't propagate style changes to the split layout nodes.

<!doctype html>
<style>
* { font-family: sans-serif; }
</style>
<script>
    onload = function() {
        document.body.offsetWidth; // force a layout
        a.setAttribute("style", null);
    }
</script>
</head>
<body>
    <span id="a" style="font-weight: bold;">hello <div>inner</div></span>
</body>

github-actions · 2025-01-18T20:01:31Z

Your pull request has conflicts that need to be resolved before it can be reviewed and merged. Make sure to rebase your branch on top of the latest master.

gmta · 2025-01-20T09:56:40Z

@kalenikaliaksandr @awesomekling some more updates:

Added a new test performing hit tests on parts of an inline continuation chain;
Fixed and test previous inline siblings not being moved to the "before" wrapper (foo<b>bar<div>baz);
Fixed and test dynamic style updates not being propagated along the continuation chain.

W/ regard to that last point, it seems to be working correctly but similar to propagating styles to anonymous wrappers (see the FIXME in that method), we might benefit from having shared computed styles at some point.

Libraries/LibWeb/Painting/PaintableBox.cpp

gmta · 2025-01-21T15:29:59Z

Hit-testing was improved with respect to continuation chains, where we now consider inline elements that are parents of block elements to be valid targets of a hit-test even if that block element has pointer-events: none set.

This fixes the <a><figure /></a> links in use on the homepage of https://tweakers.net:

Libraries/LibWeb/Painting/PaintableBox.cpp

This allows for easy child removal similar to `DOM::Node::remove()`.

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.

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.

There are many simpler APIs that we can use here. No functional changes.

Instead of ignoring any paintable immediately when they're invisible to hit-testing, consider every candidate and while the most specific candidate is invisible to hit-testing, traverse up to its parent paintable. This more closely reflects the behavior expected when wrapping block elements inside inline elements, where although the block element might have `pointer-events: none`, it still becomes part of the hit-test body of the inline parent. This makes the following link work as expected: <a href="https://ladybird.org"> <div style="pointer-events: none">Ladybird</div> </a>

circl-lastname · 2025-02-01T15:31:43Z

Fixes #959 (?)

gmta force-pushed the libweb-block-elements-inside-inline-elements branch 4 times, most recently from 92e2698 to e3732e8 Compare January 16, 2025 15:56

gmta changed the title ~~LibWeb: Correctly order block elements inside inline elements~~ LibWeb: Correctly lay out block elements inside inline elements Jan 16, 2025

kalenikaliaksandr reviewed Jan 16, 2025

View reviewed changes

Libraries/LibWeb/Layout/Node.h Outdated Show resolved Hide resolved

gmta requested a review from awesomekling January 16, 2025 16:20

gmta force-pushed the libweb-block-elements-inside-inline-elements branch 5 times, most recently from 49dd2f9 to 827da96 Compare January 17, 2025 12:11

kalenikaliaksandr requested changes Jan 17, 2025

View reviewed changes

github-actions bot added the conflicts Pull request has merge conflicts that need resolution label Jan 18, 2025

gmta force-pushed the libweb-block-elements-inside-inline-elements branch from 827da96 to 85d6717 Compare January 20, 2025 00:24

github-actions bot removed the conflicts Pull request has merge conflicts that need resolution label Jan 20, 2025

gmta force-pushed the libweb-block-elements-inside-inline-elements branch 2 times, most recently from 78e1a95 to 7b87570 Compare January 20, 2025 09:54

gmta requested a review from kalenikaliaksandr January 20, 2025 14:00

kalenikaliaksandr reviewed Jan 20, 2025

View reviewed changes

Libraries/LibWeb/Painting/PaintableBox.cpp Show resolved Hide resolved

gmta marked this pull request as draft January 21, 2025 14:14

gmta force-pushed the libweb-block-elements-inside-inline-elements branch from 7b87570 to 48c5a98 Compare January 21, 2025 15:26

gmta marked this pull request as ready for review January 21, 2025 15:27

gmta requested a review from kalenikaliaksandr January 21, 2025 15:31

kalenikaliaksandr reviewed Jan 21, 2025

View reviewed changes

Libraries/LibWeb/Painting/PaintableBox.cpp Outdated Show resolved Hide resolved

gmta added 2 commits January 22, 2025 15:42

LibWeb: Add TreeNode::remove()

5d1c472

This allows for easy child removal similar to `DOM::Node::remove()`.

LibGfx: Add Rect::unite()

33d2f5e

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.

gmta force-pushed the libweb-block-elements-inside-inline-elements branch from 48c5a98 to 071b80a Compare January 22, 2025 16:14

gmta added 3 commits January 22, 2025 17:20

LibWeb: Simplify hit testing coordinate calculations

9fdc8db

There are many simpler APIs that we can use here. No functional changes.

gmta force-pushed the libweb-block-elements-inside-inline-elements branch from 071b80a to 38dab84 Compare January 22, 2025 16:20

kalenikaliaksandr approved these changes Jan 22, 2025

View reviewed changes

gmta merged commit b7a554d into LadybirdBrowser:master Jan 23, 2025
7 checks passed

Gingeh mentioned this pull request Jan 29, 2025

New crash on discord.com #3395

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

LibWeb: Correctly lay out block elements inside inline elements #3276

LibWeb: Correctly lay out block elements inside inline elements #3276

gmta commented Jan 16, 2025 •

edited

Loading

kalenikaliaksandr left a comment

gmta commented Jan 17, 2025

kalenikaliaksandr left a comment

gmta commented Jan 17, 2025

awesomekling commented Jan 18, 2025

gmta commented Jan 18, 2025

awesomekling commented Jan 18, 2025

github-actions bot commented Jan 18, 2025

gmta commented Jan 20, 2025 •

edited

Loading

gmta commented Jan 21, 2025

circl-lastname commented Feb 1, 2025

LibWeb: Correctly lay out block elements inside inline elements #3276

LibWeb: Correctly lay out block elements inside inline elements #3276

Conversation

gmta commented Jan 16, 2025 • edited Loading

kalenikaliaksandr left a comment

Choose a reason for hiding this comment

gmta commented Jan 17, 2025

kalenikaliaksandr left a comment

Choose a reason for hiding this comment

gmta commented Jan 17, 2025

awesomekling commented Jan 18, 2025

gmta commented Jan 18, 2025

awesomekling commented Jan 18, 2025

github-actions bot commented Jan 18, 2025

gmta commented Jan 20, 2025 • edited Loading

gmta commented Jan 21, 2025

circl-lastname commented Feb 1, 2025

gmta commented Jan 16, 2025 •

edited

Loading

gmta commented Jan 20, 2025 •

edited

Loading