267029 - Absolutely positioned elements all print on first page, and the ones that don't fit aren't shown

Status: NEW

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

Description

[Edward Kuns]

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

Comment 1

[Edward Kuns]

Attachment: Sample html file to demonstrate bug

Adding attachment, as promised.

Comment 2

[OstGote!]

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.

Comment 3

[Edward Kuns]

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.

Comment 4

[mmortal03]

Was this fixed by bug 154892?

Comment 5

[fantasai]

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.

Comment 6

[mmortal03]

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

Comment 10

[Daniel Holbert [:dholbert]]

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.

Comment 17

[David Earl]

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.

Comment 18

[David Earl]

Attachment: Self contained HTML which breaks when printed, with workround in comments in the style

Comment 19

[Gérard Talbot]

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.

Comment 20

[Daniel Holbert [:dholbert]]

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?

Comment 21

[Gérard Talbot]

> 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

Comment 24

[Sean Voisen (:svoisen)]

Now that we triage by severity, setting priority to P1 to reflect backlog prioritization on this bug as either in-progress, or planned development in the near term. See https://wiki.mozilla.org/Platform/Layout#Backlog_Tracking_in_Bugzilla

Comment 25

[Rachel Tublitz [:rachel]]

S1 or S2 bugs needs an assignee - could you find someone for this bug?

Comment 26

[Sean Voisen (:svoisen)]

We're going to try to fix this first through the approach in bug 1640197. So we won't be assigning this to anyone yet. Given how long we've lived with this, will downgrade to S3 for now.

Comment 28

[Robert Ciang]

Mon dieu, 17 years old bug.

I have to use Chromium-based browsers just to overcome this situation recently.