Firefox prints one page only of long doc in a frame

Bug #271216 reported by Jan Newmarch
30
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Mozilla Firefox
Fix Released
Unknown
firefox (Ubuntu)
Fix Released
Medium
Unassigned

Bug Description

Binary package hint: mozilla-firefox

Firefox 3.01 printing: I have two frames, one containing a document that should take many pages to print. Firefox only prints one page, losing the rest. Typical site: http://www.cict.bhtafe.edu.au/subjects/ict321/bug.html
It also prints one page for multi-frame documents from web access to M/S Exchange such as http://www.cict.bhtafe.edu.au/subjects/bug/MicrosoftOutlookWebAccess.html
Another problem site is http://septemberfestival.com.au/index.php?option=com_content&task=view&id=4&Itemid=4 which prints three pages but still loses a lot of content

Package is Ubuntu 8.10 alpha5, but problem has occurred in many other distros and earlier versions of firefox.

Revision history for this message
In , Stefanh-inbox (stefanh-inbox) wrote :

If you're using absolute positioned div's you might be seeing bug 154892 or one of it's dependencies.

Revision history for this message
In , Mozbugs-jard (mozbugs-jard) wrote :

Are you able to post the URL of the page that's showing the problem yet?

Or can you create a simplified version of the page that still shows the problem that you could attach to this bug?

As it is more specific information is required from you as to the exact HTML and CSS that you're using, before anyone can start looking at this.

Revision history for this message
In , Darrenrobinson (darrenrobinson) wrote :

Appears to be related to bug #154892, seems to be affecting anyone using absolute divs, solution for now would be to use relatively positioned divs when printing, bit of a pain, but should work.

*** This bug has been marked as a duplicate of 154892 ***

Revision history for this message
In , Darrenrobinson (darrenrobinson) wrote :

Of interest only, this bug is NOT necessarily the same as bug #154892 as i have discovered by experimentation. The page printout is not affected by absolute positioning, this is a myth the layout for absolutley positioned divs works fine, it appears to the a problem with overflow. having removed all overflow attributes, the page prints in whole as a continuous output on all pages, however the float when printed is incorrectly possitioned, which is no big problem for my layout as it only contains navigation, but may be a bigger problem for someone else.

unfortunatly due to design changes and internal politics the site has not gone live yet, but the basic structure i should be able to post... you'll probably need to flesh out the layout with dummy text, as it would normally print out over 4 pages of A4/Letter size.

Revision history for this message
In , Darrenrobinson (darrenrobinson) wrote :

Created attachment 212457
HTML with embeded styles - simplified overflow clip test

Uses relativly positioned divs with overflow and clip to show this bug affects not only absolutly positioned divs.

Revision history for this message
In , Darrenrobinson (darrenrobinson) wrote :

the attachment shows the most basic form of this problem. it uses a single div with relative positioning with overflow set to hidden, and its clip set to auto. this requires the div to expand to the full content width/height, and theoretically hide any overflow. There is never any overflow when a div expands to its full width/height and so should never hide any content. The clip set to auto ensures that the region to be hidden is at the edge of the content.

Revision history for this message
In , Darrenrobinson (darrenrobinson) wrote :

just an update:

now using firefox 1.5.0.3 and this bug still with us :-)

Revision history for this message
In , Darrenrobinson (darrenrobinson) wrote :

Created attachment 223110
div positioned relatively, but with no overflow or clip specified

Revision history for this message
In , Darrenrobinson (darrenrobinson) wrote :

Created attachment 223111
dive with no styling at all

Revision history for this message
In , Vseerror (vseerror) wrote :

via testcase I see this also in windows.
good examples, but surely this is a dupe?

Revision history for this message
In , Darrenrobinson (darrenrobinson) wrote :

this bug is still with us on 1.5.0.6

Revision history for this message
In , Darrenrobinson (darrenrobinson) wrote :

(In reply to comment #10)
> via testcase I see this also in windows.
> good examples, but surely this is a dupe?
>
Wayne,
No not a dup at all, have checked, and had others check too... this is a potentially different (even if most probably related) bug to Bug #154892, but is different to that bug. This one relates specifically to non-absolutely possitioned elements, as documented in comment #4 "layout for absolutley positioned divs works
fine, it appears to the a problem with overflow" property.

see comments in both bug entries for distinction.

and yes its still in 1.5.0.7

Revision history for this message
In , Darrenrobinson (darrenrobinson) wrote :

Just tested again, and its still here in version 2.

perhaps this and the absolutely positioned bugs need to be promoted to higher priority, get some votes in... why are people still voting for trivialities related to silly gimmicks and add-ons rather than real issues witht the basics like this!

any suggestions to getting this higher on the agenda would be welcomed.

Revision history for this message
In , Stefanh-inbox (stefanh-inbox) wrote :

(In reply to comment #13)
> Just tested again, and its still here in version 2.
>
> perhaps this and the absolutely positioned bugs need to be promoted to higher
> priority, get some votes in... why are people still voting for trivialities
> related to silly gimmicks and add-ons rather than real issues witht the basics
> like this!
>
> any suggestions to getting this higher on the agenda would be welcomed.
>
Version 2 is not trunk. Trunk builds are developments builds - like a snapshot of the code from the last day's hacking. See http://www.mozilla.org/developer/#builds

Revision history for this message
In , Darrenrobinson (darrenrobinson) wrote :

apologies for the trunk mix-up. We really should have an 'ALL' option in the version list or allow multiple selection as it affects ALL versions to my knowledge - including those that are currently being worked on (last i heard anyway), can someone test against the trunk build, as the latest nightly builds don't work on my machine.

Revision history for this message
In , Wildmyron (wildmyron) wrote :

The first testcase does not print preview correctly on trunk, tested with: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a3pre) Gecko/20070228 Minefield/3.0a3pre ID:2007022804 [cairo]
The print preview has three pages: page 1 contains one line with "test 1 2 3"; page 2 is a full page of xxx paragraphs and page 3 is blank.

However, this appears to be a dupe of Bug 287642 - assuming the clip doesn't have anything to do with your problem.

Incidentally, the reason trunk builds didn't start on your machine may be explained by http://forums.mozillazine.org/viewtopic.php?p=2627112#2627112 . I believe this was fixed in trunk builds about a week ago. (Can't say for sure as I never experienced the problem.)

Revision history for this message
In , Darrenrobinson (darrenrobinson) wrote :

Yup, it would appear to be the same as Bug 287642; although it has nothing to do with the actual setting of overflow to hidden. There is a MAJOR problem with overflow for all settings.

As clip is only possible with overflow, it is hard to test without correct overflow performance. However, the good news is firefox doesnt seem to try to do anything with clip without overflow.

Problems for each overflow setting (during PRINT only) are as follows:

overflow: auto | hidden | scroll
 clipping occurs at page boundary (with or without any clip being set!)

overflow: inherit | visible
 background is extended to and clipped at penultimate page boundary regardless of height settings unless height is beyond penultimate page boundary. text flow appears to correctly continue to full extent of bounding box.

can attach examples if necessary. this is a SERIOUS problem with the print layout engine. overflow evidently needs a complete overhaul. this is in addition to all the positioning problems that the print engine has.

--
incidentally i just noticed that overflow is a vertical layout property only - will have to check the W3w specs again as its a long time since i have done so, but though this was an interesting concept/design decision.

Revision history for this message
In , Techsupport-the-colliers (techsupport-the-colliers) wrote :

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.8) Gecko/20071008 Firefox/2.0.0.8
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.8) Gecko/20071008 Firefox/2.0.0.8

I believe that you have a serious bug in this release of Firefox relating to printing.

I have been working on and testing a web site that basically has two columns defined by CSS ID selectors (menu and content). Although the pages are displaying properly, when you print a page where the content block is longer than one printed page Firefox only prints the first page and stops! When I started writing/testing this code I was using the previous version of Firefox and the printing worked! Now it doesn't although it remains "printable" in IE.

Reproducible: Always

Steps to Reproduce:
1.Visit the url listed above
2.Click the "print" button
3.Compare what prints to what is on the screen
Actual Results:
Firefox prints only one page

Expected Results:
Firefox should have printed multiple pages to encompass what is shown on the screen. (this reference is just to a reference page... the problem is critical on two other pages that are application forms that the user needs to print)

This was printing prior to the 2.0.0.8 upgrade that installed in the last couple of days.

This has now been tested on both a Windows IIS server system as well as an Apache server open to the general public.

How can I roll back to the previous release of Firefox?

Revision history for this message
In , Techsupport-the-colliers (techsupport-the-colliers) wrote :

You can also see this problem by looking at the print preview screen. The text spills off the bottom of the page in the preview

Revision history for this message
In , Vseerror (vseerror) wrote :

(In reply to comment #17)
> Yup, it would appear to be the same as Bug 287642; although it has nothing to
> do with the actual setting of overflow to hidden. There is a MAJOR problem with
> overflow for all settings.

which was duped to Bug 129941

guess the best question ATM, is this fixed on trunk?
ftp://ftp.mozilla.org/pub/firefox/nightly/latest-trunk/

Revision history for this message
Jan Newmarch (jan-newmarch) wrote :

Binary package hint: mozilla-firefox

Firefox 3.01 printing: I have two frames, one containing a document that should take many pages to print. Firefox only prints one page, losing the rest. Typical site: http://www.cict.bhtafe.edu.au/subjects/ict321/bug.html
It also prints one page for multi-frame documents from web access to M/S Exchange such as http://www.cict.bhtafe.edu.au/subjects/bug/MicrosoftOutlookWebAccess.html
Another problem site is http://septemberfestival.com.au/index.php?option=com_content&task=view&id=4&Itemid=4 which prints three pages but still loses a lot of content

Package is Ubuntu 8.10 alpha5, but problem has occurred in many other distros and earlier versions of firefox.

Revision history for this message
Mackenzie Morgan (maco.m) wrote :

There are many bugs filed in Firefox for having only the first page print. It's a cross-platform issue (I first experienced it on a Mac). Apparently a few of the cases where it happens have been sorted out, but not all of them. I'm trying to find the correct bug to mark it against.

Changed in firefox:
status: Unknown → New
Revision history for this message
Mackenzie Morgan (maco.m) wrote : Re: [Bug 271216] Re: Firefox prints one page only of long doc in a frame

Really, it's a bug in both firefox and firefox-3.0 It's been around for
well over a year.

Changed in firefox-3.0:
status: New → Confirmed
Revision history for this message
In , Vseerror (vseerror) wrote :

print output issues don't normally get dataloss keyword.

Revision history for this message
In , Daniel Holbert (dholbert) wrote :

(In reply to comment #17)
> Yup, it would appear to be the same as Bug 287642; although it has nothing to
> do with the actual setting of overflow to hidden. There is a MAJOR problem with
> overflow for all settings.

All settings but the default ('visible'), you mean.

overflow:scroll/auto/hidden all behave & are implemented roughly the same, so you're correct that this is a problem with all of those.

*** This bug has been marked as a duplicate of bug 129941 ***

Changed in firefox:
status: New → Invalid
Revision history for this message
In , Christiancallsen (christiancallsen) wrote :

I am seeing this also. I am attaching a page from www.travelocity.com - the page contains a flight reservation (anonymized). Neither Firefox nor Thunderbird can print anything but the first page. Safari prints it fine, however.

Revision history for this message
In , Christiancallsen (christiancallsen) wrote :

Created an attachment (id=359894)
HTML that should print to 4 pages but only prints first page.

Just try to print or print-preview. There should be approx. 4 pages of output.

Revision history for this message
In , Christiancallsen (christiancallsen) wrote :

Forgot to mention this: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.5) Gecko/2008120121 Firefox/3.0.5

Revision history for this message
In , Daniel Holbert (dholbert) wrote :

Confirmed on Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090130 Minefield/3.2a1pre

Likely a duplicate of another bug, though... Reduced testcase would be helpful.

Revision history for this message
GrantParnell (parngr) wrote :

With..
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.7) Gecko/2009030422 Ubuntu/8.04 (hardy) Firefox/3.0.7

Another example problem site:
http://www.ato.gov.au/businesses/content.asp?doc=/content/50506.htm

I can also point out that Konqueror 3.5.10 does print the page correctly.

Revision history for this message
In , Martijn-martijn (martijn-martijn) wrote :

Created an attachment (id=375370)
testcase

Revision history for this message
In , Daniel Holbert (dholbert) wrote :

Created an attachment (id=375376)
testcase 2

Thanks for the reduced testcase, Martijn!

I'm attaching a slightly modified version of the testcase (with correct table closing-tags, with a border on the outer div, and with all visible whitespace in the body removed for maximally-clean frametrees. :))

Revision history for this message
In , Daniel Holbert (dholbert) wrote :

"testcase" and "testcase 2" are broken as far back as Firefox 2, so this is *not* a regression.

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

Revision history for this message
GophrenOli (gophrenoli) wrote :

This bug is still present in Ubuntu 9.10 incl. latest updates and Firefox version 3.6.8 - in few month this bug will celebrate its "being reported since 2 years ago" age.

Revision history for this message
Mackenzie Morgan (maco.m) wrote : Re: [Bug 271216] Re: Firefox prints one page only of long doc in a frame

I think it was reported upstream 10 years ago.

Changed in firefox:
importance: Unknown → High
status: Invalid → Unknown
Revision history for this message
GophrenOli (gophrenoli) wrote :

"FIY" - this big is still present in LUCID with all&latest updates. Firefox 3.6.10. I checked the last mentioned URL (see entry on 2009-03-10).

Revision history for this message
Micah Gersten (micahg) wrote :

Marking this Triaged as we have an upstream bug.

Changed in firefox:
importance: High → Unknown
Changed in firefox-3.0 (Ubuntu):
importance: Undecided → Medium
status: Confirmed → Triaged
Revision history for this message
Micah Gersten (micahg) wrote :

Moving to firefox source package.

affects: firefox-3.0 (Ubuntu) → firefox (Ubuntu)
Changed in firefox:
importance: Unknown → Critical
status: Unknown → In Progress
Changed in firefox:
status: In Progress → Unknown
Changed in firefox:
status: Unknown → In Progress
Revision history for this message
In , Release-mgmt-account-bot (release-mgmt-account-bot) wrote :

In the process of [migrating remaining bugs to the new severity system](https://bugzilla.mozilla.org/show_bug.cgi?id=1789259), the severity for this bug cannot be automatically determined. Please retriage this bug using the [new severity system](https://wiki.mozilla.org/BMO/UserGuide/BugFields#bug_severity).

Changed in firefox:
importance: Critical → Unknown
Revision history for this message
In , Release-mgmt-account-bot (release-mgmt-account-bot) wrote :

The severity field is not set for this bug.
:boris, could you have a look please?

For more information, please visit [BugBot documentation](https://wiki.mozilla.org/BugBot#workflow.2Fno_severity.py).

Revision history for this message
In , Boris-chiou (boris-chiou) wrote :

This is critical before, but it seems there is no update in the previous 14 years, so mark S3 for now.

Revision history for this message
In , Daniel Holbert (dholbert) wrote :

This is mitigated by the fragmentation-fallback codepath, it looks like.

Both of the attached testcases produce 3 pages of output in current Nightly (which I think is the expected rendering), though they produce only 1 page if I toggle `layout.display-list.improve-fragmentation` to `false` (so the original issue is still present, but mostly-addressed by the fragmentation fallback).

ni=me to add an automated testcase here. But I think we can close as fixed by bug 1681052 in the same way that e.g. bug 534182 was.

Changed in firefox:
status: In Progress → Fix Released
Revision history for this message
In , Daniel Holbert (dholbert) wrote :

Created attachment 9378061
Bug 401121: Add reftests for this bug (which was fixed by the fragmentation fallback codepath). r?#layout

As noted in https://bugzilla.mozilla.org/show_bug.cgi?id=401121#c12 , this
issue was fixed by the fragmentation fallback mitigation that we landed.

This patch adds two paginated reftests based on the bug's two attached
testcases. I've modified them so that the content fits into the
reftest-snapshot canvas (while still requiring several reftest-paged pages).

Revision history for this message
In , Pulsebot-d (pulsebot-d) wrote :

Pushed by <email address hidden>:
https://hg.mozilla.org/integration/autoland/rev/110a46d27bc3
Add reftests for this bug (which was fixed by the fragmentation fallback codepath). r=TYLin

Revision history for this message
In , Smolnar (smolnar) wrote :
Revision history for this message
Mathew Hodson (mhodson) wrote :

This was fixed in Firefox 85.

Changed in firefox (Ubuntu):
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.