Adding or removing a transform-related property does not properly update multicolumn layout |
||||
Issue descriptionTo repro: try clicking to add and remove will-change: transform on the composited layers in this test: fast/multicol/composited-layer-multiple-fragments.html The rendering will be broken when will-change: transform is present a second time. If layout is forced by also tweaking a layout property like width/height on the element in a no-op way, everything is reset to a good state. I think layout needs to be dirtied for this case in StyleDifference or in LayoutBoxModelObject::styleDidChange.
,
Jun 5 2017
,
Jun 19 2017
Also happens when setting will-change to "opacity" or "z-index" (not just "transform"). So I suspect that it happens because we suddenly establish a stacking context without updating layout properly.
,
Jun 19 2017
It's correct that StyleWillChange() / StyleDidChange() doesn't mark for re-layout in this case, but that's probably fine, actually. I'm looking into a fix where we no longer call UpdateLayerPositionsAfterLayout() when we have established a new layer and come to the conclusion that we're not going to lay out. Since we're starting this update somewhere in the middle of the tree, the mechanism that normally takes care of storing PaintLayer::rare_data_->enclosing_pagination_layer doesn't work. So I'll add specialized code for this, just like the FIXME in LayoutBoxModelObject suggests.
,
Jul 5 2017
Issue 177556 has been merged into this issue.
,
Jul 21 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/337a726cfe4d5e935985fe209e0711058faa1f1a commit 337a726cfe4d5e935985fe209e0711058faa1f1a Author: Morten Stenshorne <mstensho@opera.com> Date: Fri Jul 21 22:01:39 2017 Always relayout when an object gets or loses a PaintLayer. This rids us of some crufty code, and also fixes bugs. The approach was also broken for multicol, because we started UpdatePaginationRecursive() in the middle of the tree without looking for a containing flow thread (pagination layer). This would result in the new layer erroneously not becoming paginated. Also had to update a unit test, to satisfy its requirement that the style change won't trigger layout. BUG= 616596 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_layout_tests_layout_ng Cq-Include-Trybots: master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2 Change-Id: I50ed61a7174e360259b7b786bab01cf74616fc32 Reviewed-on: https://chromium-review.googlesource.com/542915 Commit-Queue: Morten Stenshorne <mstensho@opera.com> Reviewed-by: Steve Kobes <skobes@chromium.org> Cr-Commit-Position: refs/heads/master@{#488768} [modify] https://crrev.com/337a726cfe4d5e935985fe209e0711058faa1f1a/third_party/WebKit/LayoutTests/FlagExpectations/enable-slimming-paint-v2 [add] https://crrev.com/337a726cfe4d5e935985fe209e0711058faa1f1a/third_party/WebKit/LayoutTests/fast/multicol/dynamic/add-will-change-transform-expected.html [add] https://crrev.com/337a726cfe4d5e935985fe209e0711058faa1f1a/third_party/WebKit/LayoutTests/fast/multicol/dynamic/add-will-change-transform.html [modify] https://crrev.com/337a726cfe4d5e935985fe209e0711058faa1f1a/third_party/WebKit/Source/core/layout/LayoutBoxModelObject.cpp [modify] https://crrev.com/337a726cfe4d5e935985fe209e0711058faa1f1a/third_party/WebKit/Source/core/paint/PaintInvalidationTest.cpp
,
Jul 24 2017
|
||||
►
Sign in to add a comment |
||||
Comment 1 by sheriffbot@chromium.org
, Jun 2 2017Status: Untriaged (was: Available)