The default bug view has changed. See this FAQ.

overflow:hidden, auto, & scroll cause truncation of data in Print Preview

RESOLVED FIXED in mozilla2.0b7

Status

()

Core
Printing: Output
P1
major
RESOLVED FIXED
15 years ago
16 days ago

People

(Reporter: Gabor Liptak, Assigned: bz)

Tracking

(Depends on: 1 bug, Blocks: 2 bugs, {dataloss, sec508, testcase})

Trunk
mozilla2.0b7
dataloss, sec508, testcase
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9.2 -
wanted1.9.2 +
in-testsuite +

Firefox Tracking Flags

(blocking2.0 betaN+)

Details

(Whiteboard: [testcase in comment 49], URL)

Attachments

(6 attachments, 11 obsolete attachments)

2.69 KB, patch
Details | Diff | Splinter Review
24.75 KB, text/html
Details
119.52 KB, application/pdf
Details
107.68 KB, application/x-xpinstall
Details
270.56 KB, image/png
Details
9.12 KB, patch
Details | Diff | Splinter Review
(Reporter)

Description

15 years ago
http://cbs.marketwatch.com/news/story.asp?siteid=mktw&dist=nwhwk&guid=%7B84BDE3A9%2DD52E%2D429E%2D8FD1%2DCD0697A83FB6%7D

but there should be at least 3 it seems

Comment 1

15 years ago
confirming using build 2002030908 on Win2k.

Comment 2

15 years ago
Confirmed WinXP/2002031008
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 3

15 years ago
samething, can't get to page please unfuture when there is a testcase
Status: NEW → ASSIGNED
Keywords: qawanted, testcase
Target Milestone: --- → Future
(Reporter)

Comment 4

15 years ago
free signup at:

http://cbs.marketwatch.com/login/registration.asp?siteID=mktw&returnURL=%2Fnews%2Fstory%2Easp%3Fguid%3D%7B84BDE3A9%2DD52E%2D429E%2D8FD1%2DCD0697A83FB6%7D%26siteid%3Dmktw%26archive%3Dtrue

you can get a free email at:

http://edit.yahoo.com/config/eval_register?.intl=us&new=1&.done=&.src=ym&.partner=&.p=&promo=&.last=

if you are concerned about CBS spamming you ...
(Reporter)

Comment 5

15 years ago
Created attachment 73730 [details]
here is the page saved
(Reporter)

Comment 6

15 years ago
Created attachment 73731 [details]
here is the page saved
(Reporter)

Comment 7

15 years ago
Created attachment 73732 [details]
here is the page saved

Comment 8

15 years ago
When I look at the following URL (http://www.jcp.org/jsr/detail/176.jsp), I miss
some pages on the print preview window (3 out of 6).
Is it the same bug?

Comment 9

15 years ago
all table issues as far as I can tell
Assignee: rods → karnaze
Status: ASSIGNED → NEW
Target Milestone: Future → ---

Comment 10

15 years ago
Created attachment 101620 [details]
gif-1 for upcoming test case

Comment 11

15 years ago
Created attachment 101621 [details]
gif-2 for upcoming test case

Comment 12

15 years ago
Created attachment 101622 [details]
gif-3 for upcoming test case

Comment 13

15 years ago
Created attachment 101627 [details]
somewhat reduced test case from http://www.jcp.org/jsr/detail/176.jsp that doesn't print correctly

The only problem I'm seeing is on http://www.jcp.org/jsr/detail/176.jsp, where
a table on the right hand side is getting pushed to the next page prematurely.
This test case illustrates the problem.

Updated

15 years ago
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → mozilla1.2beta

Comment 14

15 years ago
Created attachment 101629 [details] [diff] [review]
patch to fix the bug

Comment 15

15 years ago
Created attachment 101713 [details] [diff] [review]
same patch with different comments
Attachment #101629 - Attachment is obsolete: true

Comment 16

15 years ago
CCing dbaron, since the patch is touching mPrevBottomMargin logic.

Comment 17

15 years ago
Comment on attachment 101629 [details] [diff] [review]
patch to fix the bug

==== Why are all the checks needed?


+      if (autoHeight < aReflowState.availableHeight) {
+	 autoHeight += aState.mPrevBottomMargin.get();
+	 if (constrainedHeight) 
+	   autoHeight = PR_MIN(aReflowState.availableHeight, autoHeight);
+      }


Won't something like this work anyways? Or is the intent to allow autoHeight
values greater than NS_UNCONSTRAINED_SIZE?


       autoHeight += aState.mPrevBottomMargin.get();
+      PR_MIN(aReflowState.availableHeight, autoHeight);

Comment 18

15 years ago
Uh, that should've been:

       autoHeight += aState.mPrevBottomMargin.get();
+      autoHeight = PR_MIN(aReflowState.availableHeight, autoHeight);

Comment on attachment 101713 [details] [diff] [review]
same patch with different comments

>+      // When we are a bottom-margin root make sure that our last child's bottom margin 
>+      // is fully applied, but don't exceed a constrained height (otherwise, the caller may
>+      // reflow us again on a new page).

The change to this comment doesn't make sense -- the |autoHeight| variable
contains the auto height, and if the block is taller than that height and
doesn't have a specified height then I'd think part of it should end up on the
following page.  I could understand wanting to do it this way for the child's
margin, but I think it's a bad idea for borders (see below).

>XXX we were reflowed with margins taken out of avail
>+      // height, so why add them back in? Shouldn't the parent's size include this margin?

Why?  We're applying the margin of the last child of the block to the inside of
the block before computing the block's height.	In other words:

<div style="border-bottom: thin solid black;">
  <div style="margin-bottom: 1em">
  </div>
  <!-- applying margin here, so that the height of
     - the outer DIV is larger -->
</div>

>+      // XXX check for a fit, 
>+      if (autoHeight < aReflowState.availableHeight) {
>+        autoHeight += aState.mPrevBottomMargin.get();
>+        if (constrainedHeight) 
>+          autoHeight = PR_MIN(aReflowState.availableHeight, autoHeight);
>+      }
>+    }
>+
>+    // Apply borderPadding, but not to exceed a constrained height 
>+    // XXX the next-in-flow should pick up the unused padding and border 
>+    if (autoHeight < aReflowState.availableHeight) {
>+      autoHeight += borderPadding.bottom;
>+      if (constrainedHeight) 
>+        autoHeight = PR_MIN(aReflowState.availableHeight, autoHeight);
>     }

This seems like a particularly bad thing to do with borders, since if you
shrink the block because a thick border doesn't fit, the border will end up
overlapping (and obscuring) the text.

>Index: src/nsBlockReflowContext.cpp
>     if (NS_UNCONSTRAINEDSIZE != aFrameRS.availableHeight) {
>       aFrameRS.availableHeight -= aPrevBottomMargin.get();
>+      aFrameRS.availableHeight = PR_MAX(0, aFrameRS.availableHeight);
>     }

The old code seems necessary here -- this looks like it would make a block try
to take more room than is available.  That said, it seems like you might also
want a way of handling the case where the available height becomes less than
zero, but I'd think that would involve some sort of break status.

Comment 20

15 years ago
>Won't something like this work anyways? Or is the intent to allow autoHeight
>values greater than NS_UNCONSTRAINED_SIZE?

The intent was not to allow a margin alone to push the height above the avail
height. If the auto height was already larger than the avail height, then go
ahead and add it the margin.


>(From update of attachment 101713 [details] [diff] [review])
>>+      // When we are a bottom-margin root make sure that our last child's
bottom margin 
>>+      // is fully applied, but don't exceed a constrained height (otherwise,
the caller may
>>+      // reflow us again on a new page).
>
>The change to this comment doesn't make sense -- the |autoHeight| variable
>contains the auto height, and if the block is taller than that height and
>doesn't have a specified height then I'd think part of it should end up on the
>following page.

If this were done right, then probably the last line of the block should be
moved to the next page along with the bottom margin, but this is more difficult,
hence, the original XXX comment. 

>  I could understand wanting to do it this way for the child's
>margin, but I think it's a bad idea for borders (see below).

Actually, it was the margin that caused the bug, not the border. I just saw that
the border could cause a similar problem.

>
>>XXX we were reflowed with margins taken out of avail
>>+      // height, so why add them back in? Shouldn't the parent's size include
this margin?
>
>Why?  We're applying the margin of the last child of the block to the inside of
>the block before computing the block's height.	In other words:
>
><div style="border-bottom: thin solid black;">
>  <div style="margin-bottom: 1em">
>  </div>
>  <!-- applying margin here, so that the height of
>     - the outer DIV is larger -->
></div>

Oh, I didn't understand what mPrevBottomMargin really was. In your example
above, it's the outer div that is adding this in, not the inner. 

>>+      // XXX check for a fit, 
>>+      if (autoHeight < aReflowState.availableHeight) {
>>+        autoHeight += aState.mPrevBottomMargin.get();
>>+        if (constrainedHeight) 
>>+          autoHeight = PR_MIN(aReflowState.availableHeight, autoHeight);
>>+      }
>>+    }
>>+
>>+    // Apply borderPadding, but not to exceed a constrained height 
>>+    // XXX the next-in-flow should pick up the unused padding and border 
>>+    if (autoHeight < aReflowState.availableHeight) {
>>+      autoHeight += borderPadding.bottom;
>>+      if (constrainedHeight) 
>>+        autoHeight = PR_MIN(aReflowState.availableHeight, autoHeight);
>>     }
>
>>This seems like a particularly bad thing to do with borders, since if you
>>shrink the block because a thick border doesn't fit, the border will end up
>>overlapping (and obscuring) the text.

The whole last line should probably be moved to the next page.

>>
>>>Index: src/nsBlockReflowContext.cpp
>>     if (NS_UNCONSTRAINEDSIZE != aFrameRS.availableHeight) {
>>       aFrameRS.availableHeight -= aPrevBottomMargin.get();
>>+      aFrameRS.availableHeight = PR_MAX(0, aFrameRS.availableHeight);
>>     }
>
>The old code seems necessary here -- this looks like it would make a block try
>to take more room than is available.  That said, it seems like you might also
>want a way of handling the case where the available height becomes less than
>zero, but I'd think that would involve some sort of break status.

Having negative avail heights causes problem just like having negative avail
widths does (recall bug 169620).

I'll take another look at the bug and see if the line can be moved to another
page in case the margin doesn't fit. I'll also skip fixing the border/padding
issue, since it is not relevant to this bug.

Comment 21

15 years ago
Comment on attachment 101713 [details] [diff] [review]
same patch with different comments

r=dcone
Attachment #101713 - Flags: review+

Updated

15 years ago
Attachment #101713 - Flags: review+

Comment 22

15 years ago
Comment on attachment 101713 [details] [diff] [review]
same patch with different comments

wrong bug.. taking off the r.

Comment 23

15 years ago
With an example similar to that in comment #19 but inside a table cell, I'm
seeing that the bottom margin of the inner div is not part of the outer div's
final height, but is part of the cell block's final height. 

dbaron, is this the way it is supposed to work? If so, could you please explain
it a little.

From the reflow dump, it also looks like the 50px (750 twips) margin is not
being subtracted out from any avail height, which I think is the root of the
problem. 

-----

<div style="width:100px; height:835px">vertical filler</div>

<table border>
 <tr>
  <td><div style="background-color:pink">foo<div style="margin-bottom:
50px"></div></div></td>
 </tr>
</table>

           cell 0574DA70 r=2 a=390,1080 c=330,UC cnt=8515
            block 0574DAD0 r=2 a=330,1020 c=330,UC cnt=8516
             block 0574DD10 r=2 a=330,1020 c=330,UC cnt=8517
              text 0571936C r=2 a=330,1020 c=UC,UC cnt=8518
              text 0571936C d=319,274
              block 0574DE98 r=2 a=330,736 c=330,UC cnt=8519
              block 0574DE98 d=330,0
             block 0574DD10 d=330,284
            block 0574DAD0 d=330,1034
           cell 0574DA70 d=390,1080
Chris, the example in comment 23 has no border or padding on the outer div. 
Thus CSS2 margin collapsing occurs between the inner and outer div.  The example
in comment 19 has a border on the outer div, so margin collapsing cannot occur.

Updated

15 years ago
Blocks: 130939
Since the question was directed to me, I'll answer by saying that I agree with
Boris's comment 24.

Comment 26

15 years ago
So, it sounds like the cell block should be subtracting out the 750 twip margin
from the avail height when reflowing children. But will it be able to do that
before reflowing the outer div?
I think it would make more sense for a child to consider its bottom margin when
deciding whether its last line fits.
(Reporter)

Comment 28

14 years ago
This seems resolved in

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030113

Thanks

Comment 29

14 years ago
mass reassign to default owner
Assignee: karnaze → table
Status: ASSIGNED → NEW
Component: Print Preview → Layout: Tables
QA Contact: sujay → madhur
Target Milestone: mozilla1.2beta → ---

Updated

14 years ago
Target Milestone: --- → Future

Comment 30

14 years ago
print bugs
Assignee: table → printing
Component: Layout: Tables → Printing
QA Contact: madhur → sujay
Target Milestone: Future → ---

Comment 31

14 years ago
I am also seeing this on:

	http://www.bctechnology.com/

There are two pages shown in print preview but the second one is blank.  This is on:
	Mozilla 1.5b
	Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5b) Gecko/20030827

Should this be considered part of this bug or should I open a new one?

Comment 32

13 years ago
Re: comment 31: www.bctechnology.com uses the FRAME tag, which seems to indicate
bug 239795, not this bug.

The testcase seems to WFM on Firefox 0.8, but it doesn't look like the patch was
ever checked in.  Can somebody familiar with this bug check and see if it's
still valid?

Comment 33

13 years ago
Does the patch work?  If so, then I think having someone to review and
superreview would be a step in the right direction to get it checked in.

Comment 34

13 years ago
Created attachment 152113 [details]
testcase from http://oa.mei.net/oaclass/net+_712004.htm

I found this through report for bug 249401.  Using the page produced there, I
have (somewhat) simplified it to this testcase.  Notice that if you remove the
last <br clear="all">, the print preview will start showing the rest of it
correctly.

Comment 35

13 years ago
*** Bug 249401 has been marked as a duplicate of this bug. ***
*** Bug 269647 has been marked as a duplicate of this bug. ***
*** Bug 248229 has been marked as a duplicate of this bug. ***
*** Bug 274910 has been marked as a duplicate of this bug. ***
Summary: only two pages shown in Print Preview → Pages missing in print preview (only two shown)

Comment 39

12 years ago
All testcases work now except the LAST ONE with testcase name "testcase from
http://oa.mei.net/oaclass/net+_712004.htm" for Mozilla Build Id #2005032105

Comment 40

11 years ago
I am getting this problem on firefox version 2.0 at http://www.hardcoreware.net/reviews/review-347-1.htm
the third page has only 1 line. once it hit another paragraph-separating graphic, it stopped printing.  there should be many more pages in this printout.  print preview even runs off the page for this article.  print preview sure does funny things with the page. and on every page of the article, print preview is cut short to 3 pages...
prints fine in IE6.
I'm on windows XP.

Comment 41

10 years ago
> I am getting this problem on firefox version 2.0 at
> http://www.hardcoreware.net/reviews/review-347-1.htm

Confirmed. Style culprit:

div#content {overflow:hidden}

To test the hypothesis, open that page, paste the following into the address bar (should be all one line), and press Enter to execute:

javascript:document.getElementById("content").style.overflow="visible !important"; void 0;

It's a known problem with no easy end-user workaround. (But it probably belongs under a different bug than the table examples.)
(In reply to comment #41)
>
> Confirmed. Style culprit: 
> div#content {overflow:hidden}

then some of these may be dupes:
bug 154892 
bug 192129 
bug 261743 
bug 287642 

Updated

10 years ago
Duplicate of this bug: 287642

Comment 44

10 years ago
testcase in attachment 152113 [details] WFM.

another testcase for the overflow:hidden bug:

http://michaelhorowitz2.blogspot.com/

also, the testcase from bug 287642 is a simplified case. see attachment 180726 [details].

Comment 45

10 years ago
changing summary to reflect overflow:hidden problem and data truncation
Summary: Pages missing in print preview (only two shown) → overflow:hidden causes truncation of data in Print Preview

Updated

10 years ago
Blocks: 103890

Comment 46

10 years ago
added keywords dataloss, helpwanted and sec508. 

The pertinent part of section 508 is § 1194.31 (b), Functional performance criteria.

http://www.section508.gov/index.cfm?FuseAction=Content&ID=12#Functional
Keywords: dataloss, helpwanted, sec508

Updated

10 years ago

Updated

10 years ago
Duplicate of this bug: 261743

Comment 48

10 years ago
changing severity to major, as major functionality is lost, and changing OS to all, as this isn't confined to one OS.

perhaps hardware should be changed to all? someone will have to confirm that.
Severity: normal → major
OS: Windows 2000 → All

Comment 49

10 years ago
Created attachment 263032 [details]
simplified testcase of overflow:hidden print bug
Attachment #73730 - Attachment is obsolete: true
Attachment #73731 - Attachment is obsolete: true
Attachment #73732 - Attachment is obsolete: true
Attachment #101620 - Attachment is obsolete: true
Attachment #101621 - Attachment is obsolete: true
Attachment #101622 - Attachment is obsolete: true
Attachment #101627 - Attachment is obsolete: true
Attachment #152113 - Attachment is obsolete: true
Here's another recent spotting of the bug: http://www.dribin.org/dave/blog/archives/2007/12/30/why_mercurial/

Comment 51

9 years ago
CCing DHolbert since he's been looking at printing lately..

Comment 52

9 years ago
I can confirm that this issue arises in both Firefox and Thunderbird for OS X and Linux. The culprit in my case was an e-mail with an inlined style of "overflow:auto" (not hidden, but auto) on a div containing a very long table. Manually editing the source of the message to "overflow:visible" worked around the issue and enabled "normal" printing of the message.

This workaround is not practical for normal users who just want to print their e-mail.
How do other browsers handle printing of "overflow:hidden" containers?
(In reply to comment #53)
> How do other browsers handle printing of "overflow:hidden" containers?
> 

(I mean, "overflow:hidden" containers that are taller than one page -- e.g. attachment 263032 [details] )
Hardware: PC → All

Comment 55

9 years ago
Safari and Opera both print "as expected". I'm guessing IE does as well, but I'm unable to test it ATM.

(In reply to comment #53)
> How do other browsers handle printing of "overflow:hidden" containers?
> 

Updated

9 years ago
Duplicate of this bug: 434259
Duplicate of this bug: 438326
One other real-world testcase that suffers from this bug:
 http://www.theonion.com/content/news/recession_plagued_nation_demands

If I print-preview this testcase in Firefox 3.0.1, I see two pages.  The first page has article-content cut off on both the right edge and the bottom edge, and the second page is entirely blank.

The overflow:hidden frame in play there is a div with ID="wrapper", which contains most of the page content.

Comment 59

9 years ago
Created attachment 330890 [details]
Comparing Onion page in IE7, Fx2, and Fx2 with Stylish override

In response to question about other browsers, a PDF print capture from IE7, Fx2, and Fx2 with the following Stylish rule:

*{overflow:visible !important;}

(That really should be media specific, but it was just a quick test.)

Comment 60

9 years ago
Another real-world occurrence:
<http://ctrl-shift-b.blogspot.com/2008/01/art-of-separation-of-concerns.html>
(2 instead of 20+ pages in print preview, FF 3.0.1)

After modification of the CSS (removal of "overflow: hidden;" in "#main-wrapper" with Firebug), print preview is ok.

IE7 prints "as expected" (in reply to comment #53)
Duplicate of this bug: 451377
Duplicate of this bug: 456112

Updated

9 years ago
Duplicate of this bug: 425414
Summary: overflow:hidden causes truncation of data in Print Preview → overflow:hidden, auto, & scroll cause truncation of data in Print Preview

Comment 64

9 years ago
I encountered what appears to be a similar (possibly identical) problem in one of the Microsoft TechNet forums. The URL http://social.technet.microsoft.com/Forums/en-US/winserverpowershell/thread/c5f29e46-520c-443b-8494-bc27d5c61205/ can be viewed properly, but (at least on my Windows XP SP2 machine) does not preview or print correctly. I am currently using Firefox 3.0.3.
Duplicate of this bug: 460748
Blocks: 325388
Duplicate of this bug: 325388
No longer blocks: 325388

Updated

8 years ago
Duplicate of this bug: 470986
Flags: wanted1.9.2?
Flags: blocking1.9.2?
Duplicate of this bug: 478635
Duplicate of this bug: 484342
I can repro this on http://litmus.mozilla.org.   Open any Firefox test suite, and try printing with the ajax testcase modules all expanded.   You will get the data truncation.

Updated

8 years ago
Duplicate of this bug: 503311
Flags: wanted1.9.2?
Flags: wanted1.9.2+
Flags: blocking1.9.2?
Flags: blocking1.9.2-
Assignee: printing → nobody
QA Contact: sujay → printing
Duplicate of this bug: 192129

Comment 73

8 years ago
I'm surprised that this bug that was first reported in March 2002, almost 8 years ago, is taking so long to be resolved. Is it because it only has ten votes?

Comment 74

8 years ago
I think this is also related to Bug 248075.
Blocks: 521204

Comment 75

8 years ago
The latter part of bug 521068 is clearly a dupe of this bug as well. (Still not sure about comment 0 over there.)
Whiteboard: [testcase in comment 49]

Updated

8 years ago
Duplicate of this bug: 523286

Updated

8 years ago
Duplicate of this bug: 525945
Duplicate of this bug: 527690
Duplicate of this bug: 406074
Duplicate of this bug: 499956
Duplicate of this bug: 538112
Duplicate of this bug: 544527

Comment 83

7 years ago
Just to let you know this bug (and all the similar printing bugs that are still active) affect all mozilla browsers, not just FireFox (SeaMonkey, etc, all suffer the same, so it would seem that the issue lies somewhere deep-in their shared code base.

Haven't posted here for a long time, but thought I'd let you guys know that I'm still here supporting the project, even if I gave up holding my breath for this to be solved...

I think the print engine might just need scrapping and an alternative swapping in - even if its a really simple one, just for testing to see that the other apis and other hooks are behaving.

Just about to download the latest trunk and have another look at these issues.

Comment 84

7 years ago
Still here in:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.7) Gecko/20091221
Firefox/3.5.7 (.NET CLR 3.5.30729)

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100205
SeaMonkey/2.0.3

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a2pre) Gecko/20100211
Minefield/3.7a2pre (.NET CLR 3.5.30729)

Comment 85

7 years ago
(In reply to comment #83)
> Just to let you know this bug (and all the similar printing bugs that are still
> active) affect all mozilla browsers

Yes, because this bug is still open (NEW, not FIXED). Unless you're planning on contributing a patch to fix it, you should stop spamming bugs with useless comments.
Duplicate of this bug: 498223
Duplicate of this bug: 571223
Duplicate of this bug: 571891

Updated

7 years ago
Duplicate of this bug: 550679

Updated

7 years ago
Duplicate of this bug: 528951

Updated

7 years ago
Duplicate of this bug: 511550

Comment 92

7 years ago
i think it's important to know that bug 550679 seems not to be a duplicate, but a "worser" edition of this bug as not only preview, but also printout is ****. if this bug is not touched for some months again, i have to move away multiple hundrets of workstations from firefox as a default browser, i don't like to spam, but this bug is really very major and does affect much website, ok one could say that are miscoded websites, but as that are so many and the end-user won't care, this bug is a major issue which could take away firefox 3.6.x many many users! switching to chrome or others.

Comment 93

7 years ago
I was just reading O'Reilly's CSS Cookbook section 2.23 page 95, and it was recommending to use either clear:both, clear:left, clear:right as common methods and overflow:hidden as an uncommon method for clearing floats.

so if you are wondering why you are seeing this in people's web pages, this is why.  and I suspect because of books, you are going to continue to see stuff like this in people's web pages.

Updated

7 years ago
Duplicate of this bug: 586639

Comment 95

7 years ago
I just stumble upon this bug ==> http://cgi.ebay.com/BP2NY-Battery-SONY-PCG-K23-PCG-K25-PCG-K47-PCG-K37-/280509227065

On the above page you can click "Print" button (on the right side of the page) to be redirect to a more print-friendly version of the page. However, trying to print that page you'll get only 1 page sheet (both in pring preview and print output). 
The problem is overflow:auto tag in <body>. Removing the tag solved the problem and print preview, print output work just fine.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8

Comment 96

7 years ago
would it be worthwile to create a firefox add-on that walks the dom tree and removes any overflow:auto tags? ugly, but at least a workaround for those who can't edit the source of web sites?

Comment 97

7 years ago
See git://fedorapeople.org/~mcepl/clear-overflow-hidden.git for the code, and xpi file at http://mcepl.fedorapeople.org/scripts/clear-overflow-hidden.xpi

Needless to say, that it is quite a development version so bugs are present.

Comment 98

7 years ago
Matej, thanks a lot for providing this experimental add-on!

I've tried it, it helps with the testcase shown in comment 95, but it does not yet help with attachment 263032 [details]. I tweaked your add-on to remove tags with either "auth" or "hidden" overflow property values. With the tweak added, it can print attachment 263032 [details], too. I've uploaded it for testing purposes to http://kuix.de/misc/clear-overflow-hidden-v2.xpi

The current add-on (as written by Matej) will always remove such tags, whenever loading of a tab is completed. This may change functionality, so it's probably not appropriate for general recommendation.

If nobody is able to fix the core issue and make printing work of such pages, I propose: Change the workaround-add-on, so the modification is only made on-demand when a user uses a menu entry. For example, this add-on could add a new menu command next to file/print e.g. "apply bug 129941 workaround", which performs the modification.

Comment 99

7 years ago
Nice to see the work on the extension. Had a thought about that...

Considering that the bug really only applies to the specific act of printing, it makes sense that the action should be applied on demand (as kaie mentioned) -- and really only when you discover that something you printed failed.

Anything else -- like the auto-parsing of every page to look for the presence of overflow:hidden and triggering an indicator or automatically removing the style -- would require a whole lot of undue processing overhead (particularly when restoring a whole bunch of tabs).

Comment 100

7 years ago
(In reply to comment #98)
> I've tried it, it helps with the testcase shown in comment 95, but it does not
> yet help with attachment 263032 [details]. I tweaked your add-on to remove tags
> with either "auth" or "hidden" overflow property values. With the tweak added,
> it can print attachment 263032 [details], too. I've uploaded it for testing
> purposes to http://kuix.de/misc/clear-overflow-hidden-v2.xpi

Both git repository and .xpi file were updated so that script automatically doesn't change anything but just new item to the context menu ("Clear Bad Stuff"). Not sure, whether it actually does what it is supposed to do.

Comment 101

7 years ago
(In reply to comment #100)
> (In reply to comment #98)
> > I've tried it, it helps with the testcase shown in comment 95, but it does not
> > yet help with attachment 263032 [details] [details]. I tweaked your add-on to remove tags
> > with either "auth" or "hidden" overflow property values. With the tweak added,
> > it can print attachment 263032 [details] [details], too. I've uploaded it for testing
> > purposes to http://kuix.de/misc/clear-overflow-hidden-v2.xpi
> 
> Both git repository and .xpi file were updated so that script automatically
> doesn't change anything but just new item to the context menu ("Clear Bad
> Stuff"). Not sure, whether it actually does what it is supposed to do.

Could you provide a bookmarklet instead of an add-on? Advantage: you don't have to parse every page and can be manually activated only when it's needed.

Comment 102

7 years ago
(In reply to comment #101)
> Could you provide a bookmarklet instead of an add-on? Advantage: you don't have
> to parse every page and can be manually activated only when it's needed.

I don't know how to make bookmarklets and I don't want to learn it. Hint: it's an open source and whole script is http://fedorapeople.org/gitweb?p=mcepl/public_git/clear-overflow-hidden.git;a=blob_plain;f=lib/main.js;hb=HEAD

Comment 103

7 years ago
I was excited to see a potential solution to this very old problem so I thought I'd just note that I've installed the add on clear-overflow-hidden.xpi (the v2 was not available), Afterwards, I tried printing from an amazon.com search that returned multiple books and the student roster of my university's Blackboard site.  In both cases only the first page of the multipage frame/table printed. Has it worked for anyone else?

Comment 104

7 years ago
Many thanks to Matej and other friends who make this addon available and better; it does help a lot for printing in firefox. Thanks again.

Comment 105

7 years ago
As to the problem mentioned in comment 103, please try to click each "Clear Bad Stuff" shown after right click. For example, with the test webpage " http://aviatechno.free.fr/vilgenis/histoire.php ", you can get a normal print preview only if you click the 5th "Clear Bad Stuff" from the top. Hope it helps.

Comment 106

7 years ago
(In reply to comment #105)
> As to the problem mentioned in comment 103, please try to click each "Clear Bad
> Stuff" shown after right click. For example, with the test webpage "
> http://aviatechno.free.fr/vilgenis/histoire.php ", you can get a normal print
> preview only if you click the 5th "Clear Bad Stuff" from the top. Hope it
> helps.

Whoopsee!

error: An exception occurred.
Traceback (most recent call last):
  File "resource://jid0-3afubhbhxiivdy66v5t0mai87qa-jetpack-core-lib/tabs.js", line 369, in handleEvent
    this._safeDOMContentLoaded(event);
  File "resource://jid0-3afubhbhxiivdy66v5t0mai87qa-jetpack-core-lib/tabs.js", line 324, in safeDOMContentLoaded
    this._delegate.onReady(tab);
  File "resource://jid0-3afubhbhxiivdy66v5t0mai87qa-jetpack-core-lib/tabs.js", line 470, in TETT_onReady
    eventsTabDelegate.pushTabEvent("onReady", tab);
  File "resource://jid0-3afubhbhxiivdy66v5t0mai87qa-jetpack-core-lib/tabs.js", line 428, in TETT_pushTabEvent
    })(tab);
  File "resource://jid0-3afubhbhxiivdy66v5t0mai87qa-jetpack-core-lib/errors.js", line 49, in 
    return callback.apply(this, arguments);
  File "resource://jid0-3afubhbhxiivdy66v5t0mai87qa-jetpack-core-lib/tabs.js", line 427, in 
    callback(new tabConstructor(tab));
  File "resource://jid0-3afubhbhxiivdy66v5t0mai87qa-clear-overflow-hidden-lib/main.js", line 56, in 
    Array.forEach(tab.contentDocument.styleSheets, function (sh) {
  File "resource://jid0-3afubhbhxiivdy66v5t0mai87qa-clear-overflow-hidden-lib/main.js", line 58, in 
    bStuff = bStuff.concat(collectBadStylesheetRules(sh));
  File "resource://jid0-3afubhbhxiivdy66v5t0mai87qa-clear-overflow-hidden-lib/main.js", line 15, in collectBadStylesheetRules
    Array.forEach(rules, function (rule) {
  File "resource://jid0-3afubhbhxiivdy66v5t0mai87qa-clear-overflow-hidden-lib/main.js", line 16, in 
    testedStyles.forEach(function (name) {
  File "resource://jid0-3afubhbhxiivdy66v5t0mai87qa-clear-overflow-hidden-lib/main.js", line 17, in 
    if (badStyleRE.test(rule.style.getPropertyValue(name))) {
TypeError: rule.style is undefined
error: An exception occurred.
Traceback (most recent call last):
  File "resource://jid0-3afubhbhxiivdy66v5t0mai87qa-jetpack-core-lib/tabs.js", line 369, in handleEvent
    this._safeDOMContentLoaded(event);
  File "resource://jid0-3afubhbhxiivdy66v5t0mai87qa-jetpack-core-lib/tabs.js", line 324, in safeDOMContentLoaded
    this._delegate.onReady(tab);
  File "resource://jid0-3afubhbhxiivdy66v5t0mai87qa-jetpack-core-lib/tabs.js", line 470, in TETT_onReady
    eventsTabDelegate.pushTabEvent("onReady", tab);
  File "resource://jid0-3afubhbhxiivdy66v5t0mai87qa-jetpack-core-lib/tabs.js", line 428, in TETT_pushTabEvent
    })(tab);
  File "resource://jid0-3afubhbhxiivdy66v5t0mai87qa-jetpack-core-lib/errors.js", line 49, in anonymous
    return callback.apply(this, arguments);
  File "resource://jid0-3afubhbhxiivdy66v5t0mai87qa-jetpack-core-lib/tabs.js", line 427, in anonymous
    callback(new tabConstructor(tab));
  File "resource://jid0-3afubhbhxiivdy66v5t0mai87qa-clear-overflow-hidden-lib/main.js", line 56, in anonymous
    Array.forEach(tab.contentDocument.styleSheets, function (sh) {
  File "resource://jid0-3afubhbhxiivdy66v5t0mai87qa-clear-overflow-hidden-lib/main.js", line 58, in anonymous
    bStuff = bStuff.concat(collectBadStylesheetRules(sh));
  File "resource://jid0-3afubhbhxiivdy66v5t0mai87qa-clear-overflow-hidden-lib/main.js", line 13, in collectBadStylesheetRules
    var rules = sh.cssRules, badRules = [];
[Exception... "A parameter or an operation is not supported by the underlying object"  code: "15" nsresult: "0x8053000f (NS_ERROR_DOM_INVALID_ACCESS_ERR)"  location: "file:///home/matej/projekty/jetpack-sdk/packages/jetpack-core/lib/securable-module.js -> resource://jid0-3afubhbhxiivdy66v5t0mai87qa-clear-overflow-hidden-lib/main.js Line: 13"]

I am not sure what's going on here, but certainly you shouldn't have "Clear Bad Stuff" item more than once in the context menu. We'll investigate.
So the real Gecko problem in this bug, by the way, is that nsHTMLScrollFrame doesn't support splitting.  It's in the right place in the inheritance hierarchy to support splitting.  It just doesn't ever split itself across pages, or size itself appropriately on later pages.

That said, I'm not sure that using nsHTMLScrollFrame is really even the right thing.  When paginating, we might instead want to create block frames and force those blocks to clip.  That said, that approach might not be desirable for columns, where we probably do want scrollable areas within columns (but not split across them).  But maybe that's not really a problem, and people who really want scrollable areas within columns can make an inline-block rather than a block.

Comment 108

7 years ago
It is seemed the addon provided by comment 97 does not work in Firefox on Fedora 13. Please help to verify. Thanks.

Comment 109

7 years ago
(In reply to comment #108)
> It is seemed the addon provided by comment 97 does not work in Firefox on
> Fedora 13. Please help to verify. Thanks.

And addon provided by comment 100 is here no more (error 404).

Comment 110

7 years ago
(In reply to comment #109)
> (In reply to comment #108)
> > It is seemed the addon provided by comment 97 does not work in Firefox on
> > Fedora 13. Please help to verify. Thanks.
> 
> And addon provided by comment 100 is here no more (error 404).

It is there again ... not sure what happened, but maybe while syncing with and reinstalling my computer it might get removed for a moment. Sorry for inconvenience.

Comment 111

7 years ago
The only problem could be that fedorapeople doesn't provide correct MIME type for it. You may need to download it locally and install from there.

Comment 112

7 years ago
(In reply to comment #108)
> It is seemed the addon provided by comment 97 does not work in Firefox on
> Fedora 13. Please help to verify. Thanks.

If we reopen the same webpage ( e.g. http://aviatechno.free.fr/vilgenis/histoire.php ) on another new tab and right click "Clear Bad Stuff", then the print preview will be displayed normally on the Fedora 13 platform. Thanks.

Comment 113

7 years ago
Hi People, this is a nice workaround!

but however, is it not possible to fix the main cause? it's really annoying and it makes me thinking about Firefox quality if such a major bug is open for 8 years, what about you?

Comment 114

7 years ago
again 404 error when trying to download addon

Comment 115

7 years ago
Created attachment 466986 [details]
Firefox extension working around the issue (partially)

(In reply to comment #114)
> again 404 error when trying to download addon

I have no idea, what problem you have ... the file was there unchanged whole day yesterday, but hopefully this will work better for you.

Comment 116

7 years ago
(In reply to comment #114)
> again 404 error when trying to download addon

Mike, did you attempt to download my intermediate experiment from kuix.de ? I had deleted that, because it wasn't the latest one. 

Just in case fedorapeople.org is indeed experiencing problems, I've now mirrored Matej's current version from http://mcepl.fedorapeople.org/scripts/clear-overflow-hidden.xpi as http://kuix.de/mozilla/bug129941/clear-overflow-hidden-v3.xpi

Comment 117

7 years ago
yes, sorry i tried kuix.de download

Comment 118

7 years ago
Created attachment 467018 [details]
Workaround add-on context menu bug

Due to this bug I'm unable to use clear-overflow-hidden add-on.

Comment 119

7 years ago
(In reply to comment #118)
> Created attachment 467018 [details]
> Workaround add-on context menu bug
> 
> Due to this bug I'm unable to use clear-overflow-hidden add-on.

Similar problem here, with that Context Menu entry appearing 4 times.

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2.9pre) Gecko/20100817 Namoroka/3.6.9pre ID:20100817042026
Duplicate of this bug: 592636
Whiteboard: [testcase in comment 49] → [testcase in comment 49][for how to fix Gecko, see comment 107]
Duplicate of this bug: 595860
We decided we're going to try to fix this for Fx4.  This basically means:

 (1) doing what's in the second paragraph of comment 107

 (2) Changing ApplyOverflowHiddenClipping in nsFrame.cpp to clip for these cases (which, for this, includes !=visible, not just hidden)
Assignee: nobody → bzbarsky
blocking2.0: --- → betaN+
Whiteboard: [testcase in comment 49][for how to fix Gecko, see comment 107] → [testcase in comment 49][for how to fix Gecko, see comment 107 and 122]
... and this fix would apply to printing only, not to columns.
Created attachment 477042 [details] [diff] [review]
.  Don't create scrollframes for blockframes (except inline blocks) while printing, and make such blockframes clip their contents instead.
Created attachment 477045 [details] [diff] [review]
Slightly tweaked

This does the trick, though I considered factoring out the "is scrollable overflow and is block on inside and outside" check into a method on nsStyleDisplay and using it from both of the relevant callsites.  Let me know if you want that?  And what you think it's reasonable to name such a beastie?  ;)
Attachment #477042 - Attachment is obsolete: true
Attachment #477045 - Flags: review?(dbaron)
Oh, and I suppose we could explicitly mark frames that got forced into non-scrollability instead of relying on type == block plus the display struct check.  But I think that the patch is ok as-is.
Whiteboard: [testcase in comment 49][for how to fix Gecko, see comment 107 and 122] → [need review][testcase in comment 49][for how to fix Gecko, see comment 107 and 122]

Comment 127

7 years ago
how about fixprint or fixprinttags, if that's not already taken?
Jim, was that directed at me?

Comment 129

7 years ago
yes. "And what you think it's reasonable to name such a beastie?"

I was just coming up with some ideas for names.  I am not one of the developers, but I am a developer of other software, and a user and sometimes tester of ff, and if I am not mistaken, this bug is directed at fixing overflow:hidden and other problems that cripple printing, those seemed like reasonable names for anything that fixes the problem.  I hope I wasn't mistaken.
Ah.  I was asking David specifically, and "such a beastie" is 'a method implementing the "is scrollable overflow and is block on inside and outside" check'.  Which is not directly related to printing, per se, except insofar as we special-case such block during printing with this patch.

Comment 131

7 years ago
In a site I just created I used seperate styles for printing (@media print) for three elements that had "overflow:hidden". In the printing styles I changed all overflow settings to "visible". 
Still,the printout never contains more than one page, sometimes it's even cut off before the end of the forst page. So the bug seems not to be caused by the overflow hidden, auto or scroll settings. The only way to avoid it is to use a very high "heigth" or "min-heigth" setting, but on pages with less content this produces unnecessary empty pages when printing.
Here's an url: 
http://www.medialab.moz.ac.at/infos.html
The same happens on all other pages of that site whose content exceeds one page.
BTW: These pages print out fine in Safari, Google Chrome and Opera on Mac. In Firefox the bug happens both in the Mac and Windows version. IE in Win7 does the same as Firefox...
> So the bug seems not to be caused by the overflow hidden, auto or scroll
> settings.

In which case you're not seeing this bug but something totally different, right?  Given your markup, I suspect it's to do with printing floats.

For what it's worth, that page you link to prints more or less fine for me in a current trunk nightly on Mac (I get about two pages of text, then a third page with a table, then a fourth page that's empty.
Comment on attachment 477045 [details] [diff] [review]
Slightly tweaked

r=dbaron if you add comments in all three places pointing to both of the other two
Attachment #477045 - Flags: review?(dbaron) → review+
I have comments in FindDisplayData pointing to the other two, and comments in the other two pointingto FindDisplayData.  Do you want comments in the other two pointing at each other?
Whiteboard: [need review][testcase in comment 49][for how to fix Gecko, see comment 107 and 122] → [need landing][testcase in comment 49][for how to fix Gecko, see comment 107 and 122]
That would be ideal, yes.
Created attachment 477809 [details] [diff] [review]
With more comments
Attachment #477045 - Attachment is obsolete: true
Pushed http://hg.mozilla.org/mozilla-central/rev/41690fececaf

And bustage fixes:
  http://hg.mozilla.org/mozilla-central/rev/d73c25aaf89b (still create
     scrollframes for native anon stuff, so text inputs don't break when
     printing).
  http://hg.mozilla.org/mozilla-central/rev/219c6104c3a7 (annotate a test that
     now demonstrates a preexisting bug).
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Flags: in-testsuite+
Priority: P3 → P1
Resolution: --- → FIXED
Whiteboard: [need landing][testcase in comment 49][for how to fix Gecko, see comment 107 and 122] → [testcase in comment 49][for how to fix Gecko, see comment 107 and 122]
Target Milestone: --- → mozilla2.0b8
Target Milestone: mozilla2.0b8 → mozilla2.0b7

Updated

6 years ago
Depends on: 609272

Updated

6 years ago
Depends on: 609227

Comment 138

6 years ago
when can this be expected in upstream?
This shipped in Firefox 4 beta 7 (see target milestone field; Gecko 2.0* is Firefox 4.0*).  What that means in terms of "upstream" depends on what "upstream" is for you....

Updated

6 years ago
Duplicate of this bug: 258397

Comment 141

6 years ago
upstream does mean for me, the latest stable version of a Software Product, for us at the moment, this is a major problem, many pages that we frequently use have that printing issue (to many to ask them for fixing and also to many internal ones to fix) , but till now Firefox was our preferred Browser, as we use a deployment system, we reverted back to Firefox 3.5.x which does not seem to be affected from that bug (atleast with the pages we use) but now, firefox 3.5 is unmaintained, and we use also Web-based Software that currently only supports FF 3.5.x or 3.6.x, so even when 4.x is out we will have to wait some time till they can support it. so it would be really nice if this could somehow be ported back to Firefox 3.6.x
(In reply to comment #141)
> we reverted back to Firefox 3.5.x which does not seem
> to be affected from that bug (atleast with the pages we use)

In that case, you're probably hitting bug 550866, not this bug.  (They manifest the same - most or all of the content after a particular point gets cut off at a page boundary).

> it would be really nice if this could somehow
> be ported back to Firefox 3.6.x

Per above, *this* backport likely wouldn't help you -- I think you really want bug 550866's fix to be backported.

And sadly, that's non-trivial -- see bug 550866 comment 15.  Hopefully Firefox 4.0 will be out soon enough that it won't matter. :)  (And in the meantime, you can encourage the websites in question to support Firefox 4.0 beta!)
For what it's worth, this bug's fix can't be backported to 3.6 either.  It exposed some issues on websites (due to bad code on some of them, but that doesn't help us much when the site is gmail) that will involve some delicate surgery on our block layout code to fix.  There's no way that sort of thing is happening in a security update.
Depends on: 626395
Duplicate of this bug: 625403
Keywords: helpwanted, qawanted
Whiteboard: [testcase in comment 49][for how to fix Gecko, see comment 107 and 122] → [testcase in comment 49]
Duplicate of this bug: 625403
Duplicate of this bug: 322925

Updated

5 years ago
Depends on: 664803

Comment 147

5 years ago
Still reproduces in current browsers version (14.0.1)
jurtbc: doesn't reproduce for me, using the testcase on this bug. (attachment 263032 [details])  Presumably you can't reproduce with attachment 263032 [details] either, right?

Assuming I'm right on that, it'd be great if you could file a new bug for the issue you're seeing, with a URL or a testcase to demonstrate the problem.

Comment 149

5 years ago
http://www.weather.com/home-garden/mosquito/ticks-lyme-disease-20120614
When printing this page, in print preview, the comments at the bottom are cut off and only shown on page 3, when they should carry over to page 4.  I've tried using the Print Edit extension to cut out images and extra page text, but the problem still occurred, with the comments then moved to page 2 instead of 3.

This has been the same problem with Firefox since I started using it years ago.

Updated

4 years ago
Depends on: 819921

Comment 150

2 years ago
Sorry to comment on an OLD issue, but this isn't fixed as of FF40.0.2, or at least https://bugzilla.mozilla.org/show_bug.cgi?id=258397 is still an issue which is closed as a dup of this one. How do we re-open issues?
See bug 258397 comment 33.  Please file a new bug with clear steps to reproduce (and in particular the exact URL where you're seeing the problem).  Please cc me on the new bug.

Comment 152

2 years ago
(In reply to Brian from comment #149)
> http://www.weather.com/home-garden/mosquito/ticks-lyme-disease-20120614
> When printing this page, in print preview, the comments at the bottom are
> cut off and only shown on page 3, when they should carry over to page 4. 
> I've tried using the Print Edit extension to cut out images and extra page
> text, but the problem still occurred, with the comments then moved to page 2
> instead of 3.
> 
> This has been the same problem with Firefox since I started using it years
> ago.

Brian, you'll be happy to know that weather dot com fixed the problem ... they deleted the page! ^_^

Seriously, On Vacation... is correct. A new bug with a clean URL and steps-to-reproduce is needed.

Comment 153

4 months ago
Problem is still exists in Firefox trunk 53 version, we can reproduce this problem via try to print this page: http://semantic-ui.com/ - this only one example, but in real I can't print many sites! This is serious problem!

But this issue is closed. Does any open issue exists for solving this problem with printing only one page in Firefox?
I filed bug 1321803 on that specific situation.  Whether other sites where you're seeing the problem are the same issue or not is hard to tell without having the URLs.
Blocks: 1321803

Comment 155

23 days ago
Seems that also "display:flex" broke printing second page, example in file http://semantic-ui.com/dist/semantic.css:
.ui.grid {
  display: -webkit-box;
  display: -webkit-flex;
  display: flex;
}
- if I remove those rules, I can normally print full document, if give back - only one page.

Comment 156

21 days ago
I have this issue with a Dropbox Paper document and Firefox 51.0.1. Consider this document - https://paper.dropbox.com/doc/Example-Doesnt-Print-IGiuMatTWzm5i0ssHZtgP - From the app, select Print. Only the first page prints.

Comment 157

21 days ago
Yup. Too bad we didn't heed Zbarsky's advice to open a new bug in order to get more serious attention ... because whatever the original problem was has been resolved to Mozilla's satisfaction and THIS BUG IS MARKED RESOLVED ... that means no one but you and me are looking at it!!

Long story short, please open a new bug with your example of what doesn't work.
The display:flex issue looks like it's covered by bug 939897.

> Consider this document - https://paper.dropbox.com/doc/Example-Doesnt-Print-IGiuMatTWzm5i0ssHZtgP - From the app, select Print.

That looks like the same "display:flex" issue: on that page, the <div class="editor-viewport"> has display:flex and contains all the text somewhere inside it.
You need to log in before you can comment on or make changes to this bug.