Firefox prints one page only of long doc in a frame

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

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.

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 ***

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.

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.

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.

just an update:

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

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

Created attachment 223111
dive with no styling at all

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

this bug is still with us on 1.5.0.6

(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

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.

(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

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.

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.)

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.

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?

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

(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/

print output issues don't normally get dataloss keyword.

(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 ***

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.

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.

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

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.

Created an attachment (id=375370)
testcase

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. :))

"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

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).