550866 - Firefox 3.6 print-preview only shows first & last page, on articles at lds.org & TWiki

Status: RESOLVED WORKSFORME

(Core :: Printing: Output, defect)

Description

[Daniel Holbert [:dholbert]]

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.

Comment 1

[Daniel Holbert [:dholbert]]

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?

Comment 2

[Daniel Holbert [:dholbert]]

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

Comment 3

[Daniel Holbert [:dholbert]]

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

Comment 4

[Fry]

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)

Comment 5

[Daniel Holbert [:dholbert]]

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)

Comment 6

[Daniel Holbert [:dholbert]]

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

Comment 8

[Chris Lawson (gone)]

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

Comment 9

[Kevin Bailey]

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.

Comment 10

[Kevin Bailey]

Attachment: Shows example of faulty print from https://twiki.cern.ch/twiki/bin/view/TWiki/TWikiInstallationGuide

Comment 11

[Kevin Bailey]

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.

Comment 12

[Daniel Holbert [:dholbert]]

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.

Comment 13

[Bill Lancashire]

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.

Comment 14

[Chris Lawson (gone)]

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

Comment 15

[Daniel Holbert [:dholbert]]

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

Comment 16

[Daniel Holbert [:dholbert]]

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

Comment 17

[Bill Lancashire]

All understood.  Thanks.

Comment 18

[Bill Lancashire]

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

Comment 19

[Nick Whyborn]

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

Comment 20

[Nick Whyborn]

Attachment: Shows the result when saving the above web page to a local file (web page, complete), opening the saved file and then printing it.

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

Comment 21

[Nick Whyborn]

Attachment: As above but saving the print version of the twiki page to a local file.

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.

Comment 22

[Daniel Holbert [:dholbert]]

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

Comment 23

[Kevin Bailey]

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.

Comment 25

[Jon Peatfield]

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.

Comment 27

[Daniel Holbert [:dholbert]]

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.

Comment 28

[Doug]

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

Comment 32

[Jim Scott]

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

Comment 33

[Daniel Holbert [:dholbert]]

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

Comment 34

[Daniel Holbert [:dholbert]]

Based on my comments here, it looks like this was a bug for a particular release (3.6.x) which was fixed in trunk, and I was using this bug to investigate whether we needed to uplift a fix to 3.6.

We can close this as WFM.