STR: 1. Print-preview URL, and scroll down. EXPECTED RESULTS: ~4 pages ACTUAL RESULTS: 2 pages, with the second just having the "email to a friend" and the footer text. URL is: http://www.lds.org/ldsorg/v/index.jsp?hideNav=1&locale=0&sourceId=6301a41f6cc20110VgnVCM100000176f620a____&vgnextoid=e1fa5f74db46c010VgnVCM1000004d82620aRCRD This was originally reported in bug 375669 comment 4.

No issue on 1.9.1 or on mozilla-central trunk, BTW. Fix range on mozilla-central is very soon after the 1.9.1 branch: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a1pre) Gecko/20090831 Minefield/3.7a1pre Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a1pre) Gecko/20090901 Minefield/3.7a1pre http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d87974838fa9&tochange=e3e594837a30 --> bug 492627 strikes me as the fix, in that range. fantasai, any chance that's backportable to 1.9.2, or does it have too much risk of side effects?

(In reply to comment #1) > Fix range on mozilla-central is very soon after the 1.9.1 branch: Sorry, I meant "after the 1.9.2 branch" (when 1.9.2 branched off)

..and the regression range (on trunk) was: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090713 Minefield/3.6a1pre Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090714 Minefield/3.6a1pre http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b9012a18d2c6&tochange=9b4dd06e1c9d Looks like this is a regression from bug 503183. --> Adding that to "blocks" field, & removing the likely-fix (bug 492627) from 'depends on' field because otherwise Bugzilla says it'll make a bug-dependency-cycle.

Since FF 6.3.0 (I have just tried 6.3.2 today) we have problems with printing and print preview, similar to the above. The problem occurs with our in-house TWiki, which we use a lot, and some of my colleagues do a lot of printing from. The problem does not occur in the older 3.5.x branches. You can see the problem on a TWiki site like ClamAV's wiki - http://wiki.clamav.net/Main/WebHome. (Incidentally the problem doesn't seem to be present on the newer Foswiki fork (from TWiki). See this page for an example of the problem NOT being present - http://foswiki.org/System/UpgradeGuide)

I can confirm that the ClamAV link from comment 4 appears to be affected by this. (Broken in 3.6.2, working in my mozilla-central nightly)

For reference, the ClamAV site is currently running TWiki 4.3.2. (though other versions are likely affected too)

Can someone explain what, exactly, the actual problem is here? The summary is awfully generic and unhelpful; it would be good if someone could resummarize, stating *why* this is broken. (See bug 154892 as an example of a good summary for a similar-looking bug.)

I've described it at bug 571401 including a print out of the problem. The link I've found which shows the problem is at: https://twiki.cern.ch/twiki/bin/view/TWiki/TWikiInstallationGuide and I'll attach a PDF of the problem printout to this bug. As mentioned - FF on Ubuntu 9.04 showed problem, FF on Ubuntu 9.10 was OK - FF on Ubuntu 10.04 is showing the problem again.

A WORKAROUND. Using Firefox on Ubuntu. Browse to website. Press Ctrl-A to select all text. When printing go to the Options tab and check 'Print Selection Only'. This then results in a correct print.

Boris: I'm canceling your blocking1.9.3 request, because this has long been fixed on trunk, and hence will be fixed in 1.9.3 -- I identified the fix range in comment 1. (I just re-verified that it's fixed in today's nightly & broken in a 3.6 build. I tested both the lds.org url from comment 0 and the twiki url from comment 10). > Can someone explain what, exactly, the actual problem is here? > it would be good if someone could resummarize, No one's determined exactly what the problem is yet -- I just tracked down the checkin that broke this (comment 3), and the checkin that re-fixed it (comment 1). To determine what the problem is in more detail, it'd actually be helpful if someone could construct a reduced testcase, e.g. by saving a twiki page that reproduces the problem, and then stripping out unnecessary chunks until you've got *only* the bits that are required to reproduce the problem. see e.g. https://developer.mozilla.org/en/Reducing_testcases To be clear, though, this is already fixed on trunk, so (unless something re-breaks it :)) this *will* be fixed in Firefox 4.0. If we can isolate a small, well-understood & clearly-safe fix for the Gecko 1.9.2/Firefox 3.6 branch, it's possible that it could be fixed there too.

I am amazed that this huge web page printing bug in Firefox 3.6.x is not being given more attention. It is evident across all platforms tested by me and as far as I can determine effectively prevents printing of any web pages which run greater than 1 page. I first encountered this when I had to print off an important transaction for my records. This kind of bug has blocked releases in the past. Surely someone with the appropriate knowledge can work out how to apply the fix to the 1.9.2 trunk now that the 'regression' and 'fix' points on trunk are identified.

(In reply to comment #13) > Surely someone with the appropriate knowledge can work out how to apply the fix > to the 1.9.2 trunk now that the 'regression' and 'fix' points on trunk are > identified. As noted in comment 12, we need a reduced testcase in order to develop a patch that's safe for the 1.9.2 branch. Can you help us out with that? Alternatively, you can use Minefield nightly builds, which incorporate the fix.

(In reply to comment #13) > Surely someone with the appropriate knowledge can work out how to apply the fix > to the 1.9.2 trunk now that the 'regression' and 'fix' points on trunk are > identified. It's not as simple as that. In this case, the trunk-fix (bug 492627) constituted a relatively large change (with a six-patch fix), and appears to have caused at least seven regressions (look at the 'depends' list on that bug) (most of which are now fixed on trunk, but still -- that's more code that we'd have to backport to the branch). That's not the sort of fix that we generally take for branch dot releases.

In other words, a direct backport of the trunk patches probably won't work here; this needs a more targeted fix with a high degree of confidence in its regression-safety (and a reduced testcase would help greatly with that, as Chris reiterated in comment 14).

All understood. Thanks.

I guess it's just unfortunate that Gecko 1.9.2 branched after the regression but before it was noted and fixed on 'trunk'.

(In reply to comment #12) > > To determine what the problem is in more detail, it'd actually be helpful if > someone could construct a reduced testcase, e.g. by saving a twiki page that > reproduces the problem, and then stripping out unnecessary chunks until you've > got *only* the bits that are required to reproduce the problem. > see e.g. https://developer.mozilla.org/en/Reducing_testcases > Borrowing your own phrase: It's not that simple. If I save an affected twiki page to a local html file (web page, complete) and then open that saved file this problem goes away and I can print the complete web page.

The printout contains all the content though the frames have not been processed correctly.

This is the result I get if I save the print version of the twiki page to a local file, open the saved file and then print from that. The result is as far as I can tell the desired one. BTW This and the previous result were obtained with FF 3.6.4.

(In reply to comment #19) > If I save an affected twiki page to a local html file (web page, complete) and > then open that saved file this problem goes away When that happens, it's generally because the "complete" saved web page is actually missing some stylesheets that are referenced via the "@import" declaration in an HTML and/or CSS file. (save-as-complete doesn't save @imported stylesheets, sadly) So, if you look in your saved content for @import, and then find the correct stylesheets from the twiki instance to download & put them in the right locations (perhaps simplifying the @import declarations so "right location" is somewhere easier), then you should be able to reproduce the problem with your locally saved copy. Thanks for working on reducing a testcase, btw!

I've found another site which runs the version of TWiki which has this problem - here's a page which has plenty of content to show the issue: http://www.3dmcp.net/twiki/bin/view/TWiki/TWikiReleaseNotes04x00 Select print preview to see only two pages being shown. Basically - I Googled for 'TWiki-4.0.5, Tue, 24 Oct 2006, build 11822' and this should find a public site which is running on a version of TWiki which has the issue.

I've got a fairly simple test-case in the bz I just reported before I noticed this one: https://bugzilla.mozilla.org/show_bug.cgi?id=578128 the page which shows the problem isn't complex and just has a pair of nested <div>s with the style set to float:left... 578128 is probably a DUP of this one.

Marked bug 578128 as a dupe based on matching regression range & fix-range & similar symptoms. Jon's reduced testcase from bug 578128 is attachment 457055 [details]. (thanks for that, Jon!) I've confirmed that his testcase is WFM on trunk and broken in my Firefox 3.6 nightly build.

This bug has caused me to switch over to Google Chrome. I am done with Mozilla.

FWIW, these URLs preview and print just fine on Windoze XP MCE SP3 / FF 3.5.16: http://wiki.clamav.net/Main/WebHome http://www.3dmcp.net/twiki/bin/view/TWiki/TWikiReleaseNotes04x00 https://twiki.cern.ch/twiki/bin/view/TWiki/TWikiInstallationGuide

That's expected -- this bug only affects Firefox 3.6.x.