REGRESSION(r275754): Using MarkOnlyThis to make the preferred width dirty introduces unexpected state

• Component: Layout and Rendering
• Status: RESOLVED FIXED

[zalan]

WebKit's bottom-up invalidation stops marking the ancestor chain dirty at the first dirty ancestor node. 
We assume if the containing block is marked dirty all its ancestors are marked dirty as well (this process may stop at the layout boundary). 
This is how both the preferred width and needsLayout damage propagation work.
We also assume that the top-down computation may stop at the first clean node.
(Invalidation bottom-up, computation top-down (BFC))

r275754 introduces a new call to setPreferredLogicalWidthsDirty(true, MarkOnlyThis).

This call marks an individual renderer dirty. It makes the renderer a boundary node for the bottom-up invalidation (i.e bottom-up invalidation stops here).
Now if this renderer's containing block is not marked dirty, the top-down computation stops at the containing block as we see it clean.
Having a gap in the dirty chain is considered an unexpected state and it results in incorrect layout.

Consider the following case (see attached test case)

RenderView at (0,0) size 1129x620 renderer->(0x4101e9390) preferred width dirty: 1
  HTML RenderBlock at (0,0) size 1129x620 preferred width dirty: 1
    BODY RenderBody at (8,8) size 1113x604 preferred width dirty: 1
      DIV RenderBlock at (8,26) size 100x120 preferred width dirty: 0
        DIV RenderFlexibleBox at (0,0) size 120x120 preferred width dirty: 1
          DIV RenderBlock at (10,10) size 100x100 preferred width dirty: 0
 
^^^ The dirty bit on RenderFlexibleBox is the result of the new setPreferredLogicalWidthsDirty() call.

What we have here is the "marking gap" at the RenderFlexibleBox.
Assume a shirk-to-fit width type of BFC where the bottom most DIV's width dynamically changes to 100px (again, see attached test case).
The style change triggers 
1. a preferred width (bottom-up)_invalidation_, which in this case stops at RenderFlexibleBox and 
2. a layout which initiates a preferred width _computation_ as part of the BFC layout.
This preferred width computation now stops at the top most DIV (see the preferred width dirty bit).
This makes the top most DIV believe it has an up-to-date preferred width value (0px) for the subtree, while the correct value is 100px. 

r275754 also makes some slightly unrelated, incorrect assumptions e.g "Laying out this object means that its containing block is also being laid out."

[zalan]

Created attachment 436567 [details]
Test case

[zalan]

<rdar://82141454>

[zalan]

Created attachment 436571 [details]
[fast-cq]Patch

[EWS]

Committed r281662 (241015@main): <https://commits.webkit.org/241015@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 436571 [details].