546559 - In print-preview, all absolutely-positioned content past first page is piled at the top of the second page

Status: NEW

(Core :: Print Preview, defect)

Description

[Cliff]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 (.NET CLR 3.5.30729)

bug 154892 reported fixed however I see the same problem again

Reproducible: Always

Steps to Reproduce:
1.trying to print bill from site, print ok in IE
2.
3.
Actual Results:  
printing puts bottom part of page over top of page

Expected Results:  
print correctly

n/a

Comment 1

[Marco Bonardo [:mak]]

please use meaningful titles.

Also, please report here the address that you can't print correctly.

Comment 2

[Cliff]

https://2.saws.org/secure/AccountDetail/PrintView.saws

Comment 3

[Boris Zbarsky [:bzbarsky]]

Cliff, if you save the page in question (which requires a login to view, right?) as "Web page, complete", does the resulting saved page also show the problem?  If so, are you willing to attach that saved page here?

Comment 4

[Cliff]

Attachment: water bill (original testcase, html only; resources in separate attachment)

Comment 5

[Daniel Holbert [:dholbert]]

Cliff: Can you attach a zip file of the whole "Save as complete" results -- that is, the HTML file **and** the folder of resources ("PrintView.saws_files")?

Looking at the page source, it references lots of files in that folder, which are probably required to make the page render correctly (and reproduce the bug).  Right now, if I view the page you attached, it has tons of text stacked on top of other text, which I think would be correctly positioned if we had those extra files.

Comment 6

[Cliff]

Attachment: Zip of resources for water bill

Does this help?
Cliff

Comment 7

[Cliff]

Attachment: (duplicate attachment)

Comment 8

[Daniel Holbert [:dholbert]]

Yes -- much better, thank you.

I can confirm the bug.  Nothing overlaps when I view the page normally (with the supporting unzipped files). But when I print or print-preview it, the second page has tons of unreadable overlapping text.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a2pre) Gecko/20100217 Minefield/3.7a2pre ID:20100217031019

Comment 9

[Daniel Holbert [:dholbert]]

Attachment: broken printed results (PDF)

Here's a PDF of the broken printed output.

Comment 10

[Daniel Holbert [:dholbert]]

I get the same broken results in an up-to-date 3.0.19pre nightly, btw.

In Firefox 2.0.0.20, I get different, more-severely-broken results: there's just 1 page shown in print-preview, and content is painted past the bottom of that first page, right up to the window-boundary.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.19pre) Gecko/2010021704 GranParadiso/3.0.19pre
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.20) Gecko/20081217 Firefox/2.0.0.20

So, this isn't a regression.

Comment 11

[Daniel Holbert [:dholbert]]

Attachment: reduced testcase 1

Here's a reduced testcase.  Basically, the issue here is that *all* absolutely-positioned content past the first page ends up getting positioned right at the top of the second page. (with its first line hidden)

This makes content that's potentially very far apart in the normal document end up superimposed in a printed document.

Comment 12

[Daniel Holbert [:dholbert]]

Attachment: reduced testcase 2

This testcase is the same as the previous one, except I've added some left padding to one of the blocks of otherwise-overlapping text.

This padding keeps the text from ending up superimposed, and this perhaps better illustrates what's going on. (The blocks end up printed side-by-side, with no difference in vertical positioning, even though they've got very different values of the "top" property.)

Comment 13

[Daniel Holbert [:dholbert]]

Looks like bug 154892 is probably what improved this a bit, between Firefox 2.0.x & 3.0.x, as described in comment 10.

See related bug 267029.  In that bug, there is no second page, because each of the absolutely-positioned divs is only 1 line long, and so they don't have a second line to end up on the second page.  (as noted in comment 11, the first line of absolutely-positioned content past the first page currently gets hidden)

Comment 14

[Daniel Holbert [:dholbert]]

Comment on attachment 427356 [details]
water bill (original testcase, html only; resources in separate attachment)

Hiding original attachments, now that we've got a reduced testcase, since the original attachments contain personal info about submitter.

Comment 15

[Boris Zbarsky [:bzbarsky]]

So fundamentally, the problem is that the next-in-flows of the abs pos divs seem to be regular in-flow blocks created by nsContainerFrame::ReflowOverflowContainerChildren.  In particular, they always have 0 y-offset.  That seems... broken... to me.

Comment 16

[Boris Zbarsky [:bzbarsky]]

Oh, and the first lines of those divs are just on the first page but positioned off the end of it, looks like.  Also broken.

Comment 17

[fantasai]

The behavior of the next-in-flows is correct. The problem is the placement of the first-in-flow.

Comment 18

[Boris Zbarsky [:bzbarsky]]

As in, it shouldn't be on the first page?

Comment 19

[fantasai]

Right. Its position is far enough down that it should be starting on the second page, but since we can't paginate *positioning*, only break already positioned elements across pages, it gets positioned "on" the first page (except below its printable area) and breaks immediately because its content doesn't fit (leaving the first line on the first page).

Once the first-in-flow is positioned correctly, the rest of the breaking behavior should just work.

Comment 20

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

Bug 563584 is making architectural changes to the splitting of floats that would probably help things here if also applied to absolute positioning -- although applying them to absolute positioning is a bit more work.

Comment 21

[FataL]

One more affected page: http://web.ncbi.nlm.nih.gov/genomes/metaTEST/TREE.html

Comment 22

[FataL]

And one more: http://gotvdata.com/mozilla/princeton.htm

Comment 24

[Daniel Holbert [:dholbert]]

FWIW, the testcases here give me a different flavor of breakage than what used to happen.

We used to get all of the abspos stuff piled at the top of the second page. But with current Firefox Nightly, I'm just getting 1 page of output (no second page at all), and the abspos stuff simply isn't visible.

Comment 26

[Daniel Holbert [:dholbert]]

[adjusting summary, to reflect updated rendering per comment 24]

Comment 27

[Benny]

I also confronted this issue with 41.0.2, here is my page example:

<body style="height: 3000px;">
<div style="position: absolute; top:2800px;"> I Love You!</div>
</body>

output nothing when print preview or save as pdf, above page works very well on IE, Safari and Chrome when print.

Comment 28

[Boris Zbarsky [:bzbarsky]]

So at this point, how is this not just a duplicate of bug 267029?

Comment 30

[Daniel Holbert [:dholbert]]

Comment 24 does indeed sound like bug 267029. If that behavior were what we were still seeing, I think I'd agree that it'd be best to just dupe.

However, in current Nightly 46.0a1 (2016-01-13), I'm seeing the original behavior again, for the attached testcase. (I'm seeing behavior like comment 11 & comment 12). Not sure what changed; perhaps I made a mistake when retesting in comment 24.

Comment 32

[Daniel Holbert [:dholbert]]

--> Clarifying summary to indicate how this bug differs from bug 267029 (per bug 267029 comment 10).

They might really have the same underlying cause, so we might want to dupe them eventually. But the symptoms are different, which means it might be worth tracking them separately. (and a fix for one bug might not fix the other)

Comment 33

[Frank Griffith Jr]

Included in Jira S&Q22 Epic https://mozilla-hub.atlassian.net/browse/FFXP-1762 for traceability.

Comment 34

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 3 duplicates and 15 votes.
:jwatt, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 35

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Comment 36

[Daniel Holbert [:dholbert]]

Minor update here: this bug still exists and reproduces in essentially the same way as it originally did, with one minor change: the first line of the abspos content -- which was previously hidden per comment 11 -- now shows up, and it shows up at the appropriate position (though the subsequent lines are still all piled at the top of the page).

That first line only shows up by virtue of the fragmentation-fallback (about:config pref layout.display-list.improve-fragmentation) -- if I toggle that pref to false, then the first line doesn't paint at all.

So: that first line is presumably a frame in the first page's frame-tree, which is overflowing off the bottom of the first page (and was getting clipped as a result); and the rest of the abspos content is in a continuation on the second page.

Comment 37

[Daniel Tang]

Attachment: Practical example with workaround.html

This affected one of my webapps. I'm using position:absolute to left-float headings, avoiding accessibility order problems of float:right. With all the headings on page 2+ overlapping the 1st heading, they become unreadable and useless.

My workaround is to position:relative the <div> that encloses both.