User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20041001 Firefox/0.10.1 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20041001 Firefox/0.10.1 This bug is very similiar to Bug 179135 and probably shares the same cause. The difference here is information not being printed at all ... instead of information being printed on the wrong page. Both bugs share the same feature of all absolutely positioned DIVs being printed on the first page. I ran into this problem on the transaction history page of Fidelity's 401k web page ... www.401k.com. I captured the page source of the page in question and edited the page in question down to its simplest possible form that produced the same printing problem. It looks as if Mozilla, when printing, places all absolutely positioned DIVs on the first page, regardless of position. This is not a dup of bug 154892, which involves a single large DIV needing to be split into multiple pages. The bug here is multiple DIVs are printed out at their correct page position, but always and only on the first page. And if the DIVs happen to be position below the bottom of the page, the information is not printed at all. This is not a bug in display, because the page looks fine in the FireFox window. Only on printing is it screwed up. I tried the <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=122750#c27"> workaround</a> described in other bug reports. It did not help. I will attach a test case showing a bunch of DIVs that should be printed on separate pages. Reproducible: Always Steps to Reproduce: Load test page and print Actual Results: One page printed, containing only those DIVs that fit in the boundary of the first page. DIVs absolutely located lower than the bottom of the printed page do not appear on the first page (of course) and no later pages are printed. Expected Results: Multiple pages printed

Adding attachment, as promised.

Confirming testcase with Mozilla 1.8a5 build 2004102805 on WinNT4. Only one page is printed. The summary is confusing, it is only the first page printed and not all content on one page.

I think the summary describes what the bug is, from the description of other bugs. It appears that all absolutely positioned objects are printed as if on the very first page -- as if the first page was infinitely long. 8-1/2 by 1111! (grin) If those objects' position places them below the bottom of the first page, they don't appear at all. But if the first page was adjusted to be longer, you would see more of the missing objects. In bug 179135, there are some absolutely positioned objects that don't specify "top=" ... those objects print on the first page at whatever position they otherwise would print on the second or whatever later page. The combination of that bug and this bug is what lead me to my conclusion above.

Was this fixed by bug 154892?

No, 154892 paginates abspos elements that extend past the bottom of the first page. This bug is about paginating their container so that elements that /start/ beyond the first page get printed properly.

Ok, then I think this bug may be causing the behavior of Bug 226828. (In other words, I think Bug 226828 could be a duplicate of this bug.) People searching are generally going to find Bug 226828 first, though. By default, if it is made a duplicate of this, it won't show up in people's general searches, either, because general searches don't show duplicates. So, might you add some of the key words from it to this bug's description, if you do in fact make it a duplicate of this one? Thanks

See also bug 546559. In this bug here's testcase, most of the content ends up completely missing in printed output (everything below "Test Line #092" for me) -- but it turns out that if you add more lines to the absolutely-positioned div, then all lines past the first *do* appear -- at the top of the second page. That's what bug 546559 is about.

I just hit this bug - hard to believe it is not fixed after 12 years! However, I did find a work-round. If each page is an relatively positioned element with absolute contents (which don't render properly after the first page), then adding a non-zero top margin to the page element cures it. 1px is enough, and you can nudge the relative position back up with top:-1px to be exactly as intended (actually, as the margin amount doesn't seem to matter, maybe the margin actually has no effect other than to work round whatever the cause of the problem is, it's hard to tell.) I will attach a simple self-contained example which fails as is. Uncomment the two lines indicated in the style, and it works. zero margin doesn't work (nor do fractional values less than 1px), but any value >= 1 seems to work and the actual value doesn't matter. Maybe this information will help in locating the underlying cause. This bug would seem to make printing in Firefox fundamentally broken except for simple continuous pages.

A test which differ from this bug report description: http://www.gtalbot.org/BrowserBugsSection/css21testsuite/abspos-paged-002-GT.html Both Firefox 50.1 and Firefox 53.0a1 buildID=20170118211214 pass this test. Both Chrome 55.0.2883.87 and Chrome 57.0.2984.0 fail this test. The original test is: http://test.csswg.org/suites/css2.1/nightly-unstable/html4/abspos-paged-002.htm and both Firefox 50.1 and Firefox 53, indeed, fail that test.

That abspos-paged-002.htm failure seems to be a different sort of failure than what was originally reported here (in the original attachment). In the original attachment here, there's only one page, and abspos content was (and still is) truncated at the end of the first page. But in abspos-paged-002.htm, I see 5 pages printed, with the abspos text being nearly (but not entirely) pushed off the bottom of each page (with "two" at the bottom of page 1, "five" at the bottom of page 4, and page 5 being simply blank). Would you mind filing a separate bug for this issue?

> That abspos-paged-002.htm failure seems to be a different sort of failure > than what was originally reported here (in the original attachment). You are correct. abspos-paged-002 and abspos-paged-002-GT use relatively positioned and sized <div>s; attachment 164093 [details] does not do that. > But in > abspos-paged-002.htm, I see 5 pages printed, with the abspos text being > nearly (but not entirely) pushed off the bottom of each page (with "two" at > the bottom of page 1, "five" at the bottom of page 4, and page 5 being > simply blank). I see the same thing as you do. > Would you mind filing a separate bug for this issue? Bug 1332542: Absolutely positioned block inside sized relatively block are not printed at correct position