[Webkit-unassigned] [Bug 229586] New: REGRESSION(r275754): Using MarkOnlyThis to make the preferred width dirty introduces unexpected state

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=229586

            Bug ID: 229586
           Summary: REGRESSION(r275754): Using MarkOnlyThis to make the
                    preferred width dirty introduces unexpected state
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Layout and Rendering
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: zalan at apple.com
                CC: bfulgham at webkit.org, simon.fraser at apple.com,
                    zalan at apple.com

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."

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20210826/861e3eef/attachment.htm>