Closed Bug 1404868 Opened 3 years ago Closed 1 year ago

float following page-break-after disappears in print layout

Categories

(Core :: Printing: Output, defect, P3)

56 Branch
defect

Tracking

()

RESOLVED FIXED
mozilla70
Tracking Status
firefox-esr52 --- unaffected
firefox-esr60 --- wontfix
firefox-esr68 --- wontfix
firefox56 --- wontfix
firefox57 --- wontfix
firefox58 --- wontfix
firefox59 --- wontfix
firefox60 --- wontfix
firefox68 --- wontfix
firefox69 --- wontfix
firefox70 --- fixed

People

(Reporter: bachmann, Assigned: dbaron)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: regression, Whiteboard: [layout:print-triage:p1])

Attachments

(5 files)

Attached file test.html
User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0
Build ID: 20170926190823

Steps to reproduce:

Elements disappear in the print layout with page-break-after on the second page. This problem ocurse since Firefox 56. It happens in a combination of page-break-after, float and margin.

See the attachment. Its a simple screen and print layout. There are multiple pages (div) and every page includes 2 elements (A and B). Element a is float: right. Since Firefox 56 element a shows only on the frist page in the print preview and print result. (with "media emulate print" is all fine)
I've figuered that the problem is connected to the margin of the page/div. For the screen is a margin set, for the print that margin is reseted to zero. If the margin is set to none zero, for example 1px, it works.


Actual results:

Print Result:

Page 1
B  A

Page 2
B

Page 3
B


Expected results:

What is expected (and was until Firefox 56):

Print Result:

Page 1
B  A

Page 2
B  A

Page 3
B  A
Component: Untriaged → Printing: Output
Product: Firefox → Core
Last good revision: e6e712904806da25a9c8f48ea4533abe7c6ea8f4
First bad revision: d6bf703c5deaf1e328babd03d5e68ff2a4ffe10e
Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=e6e712904806da25a9c8f48ea4533abe7c6ea8f4&tochange=d6bf703c5deaf1e328babd03d5e68ff2a4ffe10e
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(dbaron)
Priority: -- → P3
So I looked into this a bit today.

I started by having a little trouble with our reflow debugging tools, and filed bug 1407059 (with a workaround).

Then I found that what seems to be happening is that the floats that are supposed to be on the second and third pages end up stuck on the PushedFloatsList of their respective blocks.  This is because those blocks are initially reflowed on the prior page to where they end up, return overflow-incomplete status, but then get pushed in their entirety to the next page and reflowed again there, without having a continuation created.  When reflowed on the next page, nsBlockFrame::DrainSelfPushedFloats doesn't pull the float back because floatOriginalParent == this.  But we also don't reflow the float again because we don't reflow the line containing its placeholder.

I need to think more about what's *supposed* to happen here.
Summary: Elements disappear in print layout with page-break-after on the second page → float following page-break-after disappears in print layout
Too late to fix in 59. We can still take a patch for 61 or possibly 60.
I filed bug #1470436 this morning, but it looks like that might be a duplicate of this one. My use case, however, does not use float. It overlaps the thead onto the tbody of a table. (Test file attached on my issue)
Regressed by: 1308876
No longer regressed by: 1308876
No longer blocks: 1308876
Regressed by: 1308876

This is not fixed by bug 1474771, so it needs further investigation.

Blocks: 521204
Whiteboard: [layout:print-triage:p1]

To my surprise, this isn't fixed by the patches in bug 1420528, so I'll need to debug further...

I have a patch queue that fixes this; I still need to write a reftest.

Assignee: nobody → dbaron
Status: NEW → ASSIGNED

This depends on the line state stored in the previous patch, and will be
used in the following patch.

I'm passing this information through the reflow state here, rather than
doing an extra pass over the frame tree in the following patch, because
I believe it's substantially better for memory locality during reflow.

Here's a try run.

Flags: needinfo?(dbaron)
Attachment #9082366 - Attachment description: Bug 1404868 - Record in the reflow state whether we're in a different page/column than before. → Bug 1404868 - Record in the reflow input whether we're in a different page/column than before.
Pushed by dbaron@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/9fe69074259e
Add reftests. r=TYLin
https://hg.mozilla.org/integration/autoland/rev/838aa6f9e0c7
Record when lines are in a different fragment than the one in which they were previously reflowed. r=TYLin
https://hg.mozilla.org/integration/autoland/rev/c3cbe1928fea
Record in the reflow input whether we're in a different page/column than before. r=TYLin
https://hg.mozilla.org/integration/autoland/rev/14d818778beb
Always reflow float placeholders when they move to a different block fragment. r=TYLin
See Also: → 1571222
No longer regressions: 1571222
Regressions: 1571222
See Also: 1571222
Flags: in-testsuite+
You need to log in before you can comment on or make changes to this bug.