User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:2.0) Gecko/20100101 Firefox/4.0
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0) Gecko/20100101 Firefox/4.0
Page 1 of 2 at http://itmanagement.earthweb.com/osrc/print.php/12068_3931691_2 and http://itmanagement.earthweb.com/osrc/print.php/3931691 will not print without using the "Print Selection" function.
Users end up wasting paper and ink by hitting "Print All" only to discover that page 1 will only print when "Print Selection" is done.
Steps to Reproduce:
1. navigate to above websites
2. click "Print All"
only page 2 prints
page 1 and 2 will both print
(In reply to comment #0)
> Steps to Reproduce:
> 1. navigate to above websites
> 2. click "Print All"
I don't see a "Print All" option on either of the URLs you provided. (Is step 2 supposed to be just "File | Print"?
(Both URLs look fine to me in print-preview, on the latest linux mozilla-central nightly, FWIW.)
Sorry for not being clear.
Print preview showed up "perfect" on my box is well. The problem only occurs when you actually print.
By "Print All", I mean:
1. navigate to the appropriate webpage
2. click Firefox button > Print > Print All (i.e., make sure the radio button for Print All is chosen as opposed to "Selection" or "Page" etc.)
Created attachment 528594 [details]
Confirmed - the first page of the printout is completely blank, when I actually print (to a PDF in my case), even though Print Preview is fine. Weird. :)
Mozilla/5.0 (X11; Linux i686; rv:6.0a1) Gecko/20110427 Firefox/6.0a1
James: Which webpage? I also use NoScript and have it configured such that it blocks scripts at the URLs in comment 0. (and as noted in comment 1 / comment 3, print preview looks fine for me, but printing-to-pdf spits out a blank first page)
Either webpage. In print preview, I get an extra page inserted in the front, containing only a link saying "Click here" in the top left corner. When I allow scripts, this extra page goes away. This is all with Firefox 4.0.1 beta, on WinXP.
I was able to reproduce the bug in comment 3 (the first page is blank in print output but not in print preview). Tested with Firefox 4.0.1 on Ubuntu. This problem did not occur in Firefox 3.6 (on Ubuntu), so this must be a regression from between those releases. Reduced testcase coming up.
The issue with the extra page inserted in the front during print preview (comment 4) was due to the noscript elements. This extra page was also included in the print output, and has nothing to do with this bug.
Created attachment 531449 [details]
This testcase reproduces the bug: when you print, the first page is blank, but print preview is correct.
The bug has to do with our old friends float, clear, and overflow:hidden (the source of many "missing in print/print preview" bugs). This bug should now be ready for a developer to look at it.
Note: this testcase is reduced from 130 KB of webpage code...
Created attachment 531453 [details]
pdf printout from testcase
on Firefox 4.0.1 on Ubuntu
Thanks James - that reduced testcase is quite helpful!
Good news, though -- it looks like this has become fixed in trunk, in the 2 weeks since Comment 3. Both the original URL & james' testcase are WORKSFORME in my nightly
Mozilla/5.0 (X11; Linux x86_64; rv:6.0a1) Gecko/20110506 Firefox/6.0a1
...but still broken for me in Firefox 4.0.1 (so it wasn't fixed by a system update or something).
Tracking down the nightly fix-range, & will report back after that...
That includes the fix for another printing bug, bug 652178 - possibly a dupe of that?
Yeah, bug 652178 looks like the most likely thing to be related, in that push log.
The testcase there is a bit different from the one here, though, and I don't think there's any printing-vs-print-preview distinction on that bug, so this probably isn't an exact duplicate. So, I'm resolving as WORKSFORME with dependency on that bug.
WORKSFORME --> I cannot reproduce the problem
DUPLICATE --> different (or same) description of symptoms
fixed or being fixed under a different bug report.
This is not a "WORKSFORME" case.
For definitions, see https://bugzilla.mozilla.org/page.cgi?id=fields.html#status
I'm using case "(b)" of WORKSFORME there. ('the bug was present once, but is now not reproducible (and so was probably fixed in another bug)')
(In this case, it seems likely that 652178 fixed it, but until someone's confirmed that e.g. by a local backout, it's better bug-hygiene to use WORKSFORME.)
OK, I've confirmed by local backout that bug 652178's checkin (ff87496ea7fc) was indeed what fixed this.
Updating resolution to FIXED by that bug's patch for now, since AFAICT this isn't an exact duplicate, per comment 12. (in particular, the fact that print-preview was unaffected here, while printing was broken)
Incidentally, in debug builds, this bug's reduced testcase triggers the "SameCOMIdentity" assertion from Bug 485893 when I print (but not when I print-preview).
We trigger that assertion regardless of whether cset ff87496ea7fc (the fix for the blank first page) is applied.
I've noted this in bug 485893 comment 4.
Don't we trigger that assertion when we print almost anything?
Possibly; bug 485893 suggests that we trigger it when we print anything with iframes, at least.
I was mostly mentioning it because it seemed interesting that this bug's testcase _only_ triggers it when actually printing, not when print-previewing (whereas in bug 485893's testcase, we trigger it in both cases).
(In reply to comment #12)
> Yeah, bug 652178 looks like the most likely thing to be related, in that
> push log.
> The testcase there is a bit different from the one here, though
Would it make sense then to make the testcase here into a printing reftest? (not that I know offhand how to do that myself, or could even get to it for a bit.)
(sorry, somehow the resolution accidentally got changed on my last comment)
That would be great ("reftest-print" is the magic word to search for in MXR for examples of those). But sadly, I doubt that such a test would actually succeed in catching this bug.
AFAIK, print reftest rendering is more similar to print-preview than to actual printing (or at least, it's no closer to actual printing than print-preview is), so I doubt it would hit the bug that was being exposed here.
Still, probably worth a shot, if someone gets the time!