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
please use meaningful titles. Also, please report here the address that you can't print correctly.
Component: General → Print Preview
Product: Firefox → Core
QA Contact: general → printing
Summary: 154892 → Unable to correctly print an invoice from a website
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?
Created attachment 427356 [details] water bill (original testcase, html only; resources in separate attachment)
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.
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
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: x86 → All
Version: unspecified → Trunk
Created attachment 427395 [details] broken printed results (PDF) Here's a PDF of the broken printed output.
I get the same broken results in an up-to-date 3.0.19pre nightly, btw. In Firefox 126.96.36.199, 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:188.8.131.52pre) Gecko/2010021704 GranParadiso/3.0.19pre Mozilla/5.0 (X11; U; Linux i686; en-US; rv:184.108.40.206) Gecko/20081217 Firefox/220.127.116.11 So, this isn't a regression.
Created attachment 427408 [details] 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.
Summary: Unable to correctly print an invoice from a website → In print-preview, all absolutely-positioned content past first page gets piled at the top of second page
Created attachment 427411 [details] 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.)
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)
Depends on: 154892
Summary: In print-preview, all absolutely-positioned content past first page gets piled at the top of second page → In print-preview, all absolutely-positioned content past first page gets piled at the top of second page (with first line hidden)
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.
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.
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.
blocking2.0: --- → ?
The behavior of the next-in-flows is correct. The problem is the placement of the first-in-flow.
As in, it shouldn't be on the first page?
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.
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.
blocking2.0: ? → -
One more affected page: http://web.ncbi.nlm.nih.gov/genomes/metaTEST/TREE.html
And one more: http://gotvdata.com/mozilla/princeton.htm
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.
[adjusting summary, to reflect updated rendering per comment 24]
Summary: In print-preview, all absolutely-positioned content past first page gets piled at the top of second page (with first line hidden) → In print-preview, all absolutely-positioned content past first page is missing
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.
So at this point, how is this not just a duplicate of bug 267029?
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.
--> 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)
Summary: In print-preview, all absolutely-positioned content past first page is missing → In print-preview, all absolutely-positioned content past first page is piled at the top of the second page
You need to log in before you can comment on or make changes to this bug.