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

confirming using build 2002030908 on Win2k.

Confirmed WinXP/2002031008

samething, can't get to page please unfuture when there is a testcase

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

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?

all table issues as far as I can tell

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.

CCing dbaron, since the patch is touching mPrevBottomMargin logic.

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

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.

>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 on attachment 101713 [details] [diff] [review] same patch with different comments r=dcone

Comment on attachment 101713 [details] [diff] [review] same patch with different comments wrong bug.. taking off the r.

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.

Since the question was directed to me, I'll answer by saying that I agree with Boris's comment 24.

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.

This seems resolved in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030113 Thanks

mass reassign to default owner

print bugs

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?

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?

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.

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.

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

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

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.

> 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

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

changing summary to reflect overflow:hidden problem and data truncation

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

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.

Here's another recent spotting of the bug: http://www.dribin.org/dave/blog/archives/2007/12/30/why_mercurial/

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

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

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

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.

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

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)

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.

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.

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?

I think this is also related to Bug 248075.

The latter part of bug 521068 is clearly a dupe of this bug as well. (Still not sure about comment 0 over there.)

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.

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)

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

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.

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.

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

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?

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.

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.

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

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

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

(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

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?

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.

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.

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

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

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

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

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.

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

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?

again 404 error when trying to download addon

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

(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

yes, sorry i tried kuix.de download

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

(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

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)

... and this fix would apply to printing only, not to columns.

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? ;)

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.

how about fixprint or fixprinttags, if that's not already taken?

Jim, was that directed at me?

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.

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

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?

That would be ideal, yes.

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

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

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.

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.

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.

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.

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

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.

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.

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.

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.

I had this problem today, 4/28/2017, (could only print the first page of gmail), and posted my solution at Bug 258397.