325388 - Will not print whole documents, only partial div's

Status: RESOLVED DUPLICATE of bug 129941

(Firefox :: General, defect)

Description

[Darren Robinson]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1

Major problem with firefox. Documents constructed out of correctly written DIVs and CSS controlled layout, do not print correctly. a site that i am working on, and this is not the first time, just the first time i thought to report it, does not print yet is cross browser compatible and renders identically on IE(windows & Mac), Firefox, Safari, Netscape 7... but print out from firefox does not look like the output on screen. page is constructed in three distinct stages... (1) a header, (2) the main body of text with side panel for navigation, and (3) a footer. firefox prints one page for the header the rest of the page is blank, another page for the main content (only 1 page with  content cut at the page limit, i.e. half words and graphics on the bottom line) which should, and does in other browsers, go on for a couple of pages, followed by another page for the footer, again for which the rest of the page is blank. it appears fire fox is incorrectly separating the three main containing DIVs, and then only printing to the page limit for each, not continuing on the next page. Currently havig to use IE or Safari to output to the printer... which is annoying.

will post the url for the site i am developing once it goes live later this week... (wanted to print out for a presentation, but hey ho...)

Reproducible: Always

Steps to Reproduce:
1. load any page constructed only of divs, where the main content is beyond the page limits for a single page
2. choose landscape print mode (the normal orientation of screen content)
3. print or preview
4. compare to what you seen on screen?!



Expected Results:  
Should print all the document as on screen (modified to accomodate width accordingly)

running Mac OS X 10.2.6
firefox (all versions... i have 1.0 1.5rc3 and currently using 1.5.0.1rc1)
have the Default Theme with the following extensions installed:
DOM Inspector 1.8
Talkback 1.5
Adblock 0.5.2.039
PDF Download 0.5.1.2
Fasterfox 1.0.3
WebDeveloper 0.9.4
TickerFox 0.2.6
ChatZilla 0.9.69.1

also it makes no difference how previewed or printed from firefox, all come out pretty much the same.

Comment 1

[Stefan [:stefanh]]

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

Comment 2

[GAThrawn]

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.

Comment 3

[Darren Robinson]

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

Comment 4

[Darren Robinson]

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.

Comment 5

[Darren Robinson]

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

Comment 6

[Darren Robinson]

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. 

Comment 7

[Darren Robinson]

just an update:

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

Comment 8

[Darren Robinson]

Attachment: div positioned relatively, but with no overflow or clip specified

Comment 9

[Darren Robinson]

Attachment: dive with no styling at all

Comment 10

[Wayne Mery (:wsmwk)]

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

Comment 11

[Darren Robinson]

this bug is still with us on 1.5.0.6

Comment 12

[Darren Robinson]

(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

Comment 13

[Darren Robinson]

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.

Comment 14

[Stefan [:stefanh]]

(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

Comment 15

[Darren Robinson]

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.

Comment 16

[Arie Paap [:wildmyron]]

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

Comment 17

[Darren Robinson]

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.

Comment 18

[Wayne Mery (:wsmwk)]

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

Comment 19

[Wayne Mery (:wsmwk)]

print output issues don't normally get dataloss keyword.

Comment 20

[Daniel Holbert [:dholbert]]

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