Block frame with definite block-size requests extra continuation of zero block-size in a small block-size multicol
Categories
(Core :: Layout, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox99 | --- | fixed |
People
(Reporter: TYLin, Assigned: TYLin)
References
Details
Attachments
(3 files)
See the attached testcase 1.
In a multicol container with a very small block-size, there is a simple unbreakable block with a definite block-size. We create an extra continuation even if it runs out of its block-size in the first column. It's invisible unless the unbreakable has outline
for example.
I suspect we use a wrong nsReflowStatus
in nsBlockFrame::ComputeFinalBSize
.
https://searchfox.org/mozilla-central/rev/c12a59323ee46b29b90c9917a3a7a70ea714ffec/layout/generic/nsBlockFrame.cpp#7764-7784
Assignee | ||
Updated•3 years ago
|
Assignee | ||
Comment 1•3 years ago
|
||
ComputeFinalBSize() gets most of its input parameters from BlockReflowInput's
members. Passing BlockReflowInput into it directly so that it can access more
precomputed data in BlockReflowInput such as ContentBEnd()
.
This is a preparation for the next part that is going to rewrite a large portion
of ComputeFinalBSize().
Assignee | ||
Comment 2•3 years ago
|
||
The code at the end of ComputeFinalBSize() does not handle
"box-decoration-break:clone" and the cases where the block frame's reflow status
can change from incomplete to complete. This patch is an attempt to fix all the
possible scenarios.
Depends on D138966
Updated•3 years ago
|
Assignee | ||
Updated•3 years ago
|
Comment 5•3 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/049e60e0ba2c
https://hg.mozilla.org/mozilla-central/rev/bde7633d8c5c
Description
•