1404868 - float following page-break-after disappears in print layout

Status: RESOLVED FIXED

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

Description

[Eric]

Attachment: 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

Comment 1

[Jet Villegas (inactive)]

Last good revision: e6e712904806da25a9c8f48ea4533abe7c6ea8f4
First bad revision: d6bf703c5deaf1e328babd03d5e68ff2a4ffe10e
Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=e6e712904806da25a9c8f48ea4533abe7c6ea8f4&tochange=d6bf703c5deaf1e328babd03d5e68ff2a4ffe10e

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 3

[Liz Henry (:lizzard) (relman/hg->git project)]

Too late to fix in 59. We can still take a patch for 61 or possibly 60.

Comment 4

[Kyle McNally]

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)

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: Bug 1404868 - Add reftests.

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: Bug 1404868 - Record when lines are in a different fragment than the one in which they were previously reflowed.

This will be used in the following patch.

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: Bug 1404868 - Record in the reflow input whether we're in a different page/column than before.

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.

Comment 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: Bug 1404868 - Always reflow float placeholders when they move to a different block fragment.

Comment 12

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Here's a try run.

Comment 13

[Pulsebot]

Pushed by [e-mail]:
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

Comment 14

[Bogdan Tara[:bogdan_tara | bogdant]]

https://hg.mozilla.org/mozilla-central/rev/9fe69074259e
https://hg.mozilla.org/mozilla-central/rev/838aa6f9e0c7
https://hg.mozilla.org/mozilla-central/rev/c3cbe1928fea
https://hg.mozilla.org/mozilla-central/rev/14d818778beb