Open Bug 267029 Opened 17 years ago Updated 13 days ago

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

Categories

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

x86
All
defect

Tracking

()

People

(Reporter: edward.kuns, Unassigned)

References

(Depends on 1 open bug, Blocks 3 open bugs)

Details

(Whiteboard: [layout:print-triage:p1][layout:backlog][frag2020])

Attachments

(2 files)

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.
Depends on: 154892
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
Duplicate of this bug: 415029
Duplicate of this bug: 474953
Duplicate of this bug: 226828
No longer depends on: 154892
Flags: blocking1.9.2?
Assignee: printing → nobody
QA Contact: printing
Flags: blocking1.9.2? → blocking1.9.2-
Blocks: 521204
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.
Depends on: 179135
Duplicate of this bug: 426909
Duplicate of this bug: 508321
Summary: Absolutely positioned elements all print on first page → Absolutely positioned elements all print on first page, and the ones that don't fit aren't shown
Duplicate of this bug: 1174076
Duplicate of this bug: 1239322
Duplicate of this bug: 883073
Duplicate of this bug: 1106301
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.
See Also: → 546559
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?
Flags: needinfo?(bugzilla)
> 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
Flags: needinfo?(bugzilla)
Duplicate of this bug: 1429380
Whiteboard: [layout:print-triage:p1]
Blocks: 1601429
Whiteboard: [layout:print-triage:p1] → [layout:print-triage:p1][layout:backlog:2020q1]
Whiteboard: [layout:print-triage:p1][layout:backlog:2020q1] → [frag2020]
Whiteboard: [frag2020] → [layout:print-triage:p1][layout:backlog:2020q1][frag2020]
Whiteboard: [layout:print-triage:p1][layout:backlog:2020q1][frag2020] → [layout:print-triage:p1][layout:backlog:2020q1][frag2020]
Blocks: 1619671
Whiteboard: [layout:print-triage:p1][layout:backlog:2020q1][frag2020] → [layout:print-triage:p1][layout:backlog:78][frag2020]
Duplicate of this bug: 1632516
Whiteboard: [layout:print-triage:p1][layout:backlog:78][frag2020] → [layout:print-triage:p1][layout:backlog:78]
Whiteboard: [layout:print-triage:p1][layout:backlog:78] → [layout:print-triage:p1][layout:backlog:78][frag2020]

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

Priority: -- → P1
Severity: normal → S2
Whiteboard: [layout:print-triage:p1][layout:backlog:78][frag2020] → [layout:print-triage:p1][layout:backlog][frag2020]

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

Flags: needinfo?(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.

Severity: S2 → S3
Depends on: 1640197
Flags: needinfo?(svoisen)
Priority: P1 → P2
Duplicate of this bug: 1677099
You need to log in before you can comment on or make changes to this bug.