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. Reproducible: Always Steps to Reproduce: 1. navigate to above websites 2. click "Print All" 3. Actual Results: only page 2 prints Expected Results: page 1 and 2 will both print
Component: General → Printing: Output
Product: Firefox → Core
QA Contact: general → printing
Version: unspecified → 2.0 Branch
(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.)
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
OS: Windows XP → All
Hardware: x86 → All
Summary: Page 1 will not print → First printed page is blank (aside from header/footer), despite being fine in Print Preview, on itmanagement.earthweb.com articles
Version: 2.0 Branch → Trunk
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
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...
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...
Fix range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=557165a66267&tochange=88d3c5bde0ba 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.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Depends on: 652178
Resolution: --- → WORKSFORME
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)
Resolution: WORKSFORME → FIXED
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.)
Status: RESOLVED → UNCONFIRMED
Ever confirmed: false
Resolution: FIXED → ---
(sorry, somehow the resolution accidentally got changed on my last comment)
Status: UNCONFIRMED → RESOLVED
Last Resolved: 8 years ago → 8 years ago
Resolution: --- → FIXED
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!
You need to log in before you can comment on or make changes to this bug.