Open
Bug 1374479
Opened 7 years ago
Updated 2 years ago
multicol incremental reflow state alternation
Categories
(Core :: Layout: Columns, defect, P3)
Core
Layout: Columns
Tracking
()
REOPENED
Tracking | Status | |
---|---|---|
firefox57 | --- | affected |
People
(Reporter: dbaron, Unassigned)
References
Details
Attachments
(3 files)
In my work on bug 1308876, a new test failure appeared recently, which was an assertion failure for the crashtest layout/generic/crashtests/1015844.html . This assertion failure was also associated with a layout difference in the contents of the test.
I minimized the testcase for the layout difference, started to debug it, and realized that the reason it wasn't present without the patch to bug 1308876 was the resize reflow we do once we determine that a scrollbar isn't needed. If I avoid this reflow using 'html { overflow: hidden }' then I can see the problem on trunk, without the patch.
Steps to reproduce:
1. load attached testcase
2. change the zoom level
Actual results: With each change in zoom, the testcase alternates between having three versus four purple-ish boxes.
Expected results: The testcase should be consistent in the number of boxes no matter what the zoom level.
Note that it's possible to observe different layouts at the same zoom level by doing:
Ctrl+0 (go to default zoom level)
Ctrl++ (increase zoom)
Ctrl++ (increase zoom)
Ctrl+0 (go to default zoom level)
since this sequence has two steps at the default zoom level that have an even number of other states between them.
Reporter | ||
Updated•7 years ago
|
Summary: multicol incremental reflow bug → multicol incremental reflow state alternation
Reporter | ||
Comment 1•7 years ago
|
||
This is a diff of the GECKO_DISPLAY_REFLOW_RULES_FILE output from the third and the eighth reflows in the sequence:
(1) load
(2) zoom in (Ctrl++)
(3) zoom default (Ctrl+0)
(4) zoom in
(5) zoom in
(6) zoom default
(7) zoom in
(8) zoom default
Reporter | ||
Comment 2•7 years ago
|
||
At least part of the problem here is fundamental to the way our column code works: mLastBalanceBSize intentionally persists state across reflows. That massively increases the potential for bugs like this.
But there's still the question of why we get different results.
Reporter | ||
Comment 3•7 years ago
|
||
I think a bunch of the problem comes down to the inner columnset returning a height of 0 most but not all of the time... and only occasionally reporting the correct 100px height.
Reporter | ||
Comment 4•7 years ago
|
||
I suspect the underlying problem causing the oscillation is that multicols don't seem to honor their specified height in a paginated context. The examples here show that; the inner blue multicol should always be 80px tall (sometimes split), not just when it's not inside the outer yellow one. I think this is mainly due to this code:
https://searchfox.org/mozilla-central/rev/ae94cfb36d804727dfb38f2750bfcaab4621df6e/layout/generic/nsColumnSetFrame.cpp#911-914
... though I'm also not sure if nsColumnSetFrame has the necessary code to consume only the remaining height in a continuation of a multicol with a specified height.
Updated•7 years ago
|
Priority: -- → P3
Comment 5•7 years ago
|
||
I thought it might be significant that with the fix for Bug 1411765 the assert count mentioned in layout/generic/crashtests/crashtest.list associated with this bug goes down from 543 to 11.
Updated•6 years ago
|
Component: Layout → Layout: Columns
Comment 6•5 years ago
•
|
||
The tests in comment 0 and comment 4 work as expected after enabling column-span in bug 1426010.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WORKSFORME
Reporter | ||
Comment 7•5 years ago
|
||
I'd like to leave this open unless we've fixed the underlying problems, even if the initial testcase doesn't still trigger it. Or has something changed both of:
- persisting
mLastBalanceBSize
across reflows - not honoring specified height in a paginated context
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Comment 8•5 years ago
|
||
The column container's specified height should've been honored [1] in a paginated context now, but the persisting mLastBalanceBSize
across reflow can still be an issue.
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•