Last Comment Bug 652929 - First printed page is blank (aside from header/footer), despite being fine in Print Preview, on itmanagement.earthweb.com articles
: First printed page is blank (aside from header/footer), despite being fine in...
Status: RESOLVED FIXED
: regression, testcase
Product: Core
Classification: Components
Component: Printing: Output (show other bugs)
: Trunk
: All All
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
http://itmanagement.earthweb.com/osrc...
Depends on: 652178
Blocks: 521204
  Show dependency treegraph
 
Reported: 2011-04-26 12:53 PDT by Nick
Modified: 2011-05-11 11:29 PDT (History)
7 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
example printout (33.38 KB, application/x-pdf)
2011-04-27 08:00 PDT, Daniel Holbert [:dholbert]
no flags Details
reduced testcase (1.09 KB, text/html)
2011-05-10 13:39 PDT, James Napolitano
no flags Details
pdf printout from testcase (6.33 KB, application/pdf)
2011-05-10 13:42 PDT, James Napolitano
no flags Details

Description Nick 2011-04-26 12:53:21 PDT
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
Comment 1 Daniel Holbert [:dholbert] 2011-04-26 23:02:17 PDT
(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.)
Comment 2 Nick 2011-04-27 06:21:09 PDT
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.)
Comment 3 Daniel Holbert [:dholbert] 2011-04-27 08:00:24 PDT
Created attachment 528594 [details]
example printout

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
Comment 4 James Napolitano 2011-04-27 21:03:53 PDT
When I have all javascript on that webpage disabled (by NoScript), then, in print preview, I get a mostly blank first page, followed by the full 2 other pages. Maybe this is due to all the <noscript> elements on the webpage. Not sure if this has anything to do with the problem with printing.
Comment 5 Daniel Holbert [:dholbert] 2011-04-27 21:12:11 PDT
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)
Comment 6 James Napolitano 2011-04-27 22:02:42 PDT
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.
Comment 7 James Napolitano 2011-05-10 13:32:08 PDT
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.
Comment 8 James Napolitano 2011-05-10 13:39:54 PDT
Created attachment 531449 [details]
reduced testcase

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...
Comment 9 James Napolitano 2011-05-10 13:42:58 PDT
Created attachment 531453 [details]
pdf printout from testcase

on Firefox 4.0.1 on Ubuntu
Comment 10 Daniel Holbert [:dholbert] 2011-05-10 13:58:20 PDT
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...
Comment 11 Daniel Holbert [:dholbert] 2011-05-10 14:06:07 PDT
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?
Comment 12 Daniel Holbert [:dholbert] 2011-05-10 14:11:15 PDT
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.
Comment 13 bruce korb 2011-05-10 14:27:43 PDT
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.
Comment 14 Daniel Holbert [:dholbert] 2011-05-10 15:25:18 PDT
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.)
Comment 15 Daniel Holbert [:dholbert] 2011-05-10 16:12:52 PDT
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)
Comment 16 Daniel Holbert [:dholbert] 2011-05-10 16:30:27 PDT
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.
Comment 17 Timothy Nikkel (:tnikkel) 2011-05-10 16:52:55 PDT
Don't we trigger that assertion when we print almost anything?
Comment 18 Daniel Holbert [:dholbert] 2011-05-10 16:56:59 PDT
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).
Comment 19 James Napolitano 2011-05-11 11:15:37 PDT
(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.)
Comment 20 James Napolitano 2011-05-11 11:18:14 PDT
(sorry, somehow the resolution accidentally got changed on my last comment)
Comment 21 Daniel Holbert [:dholbert] 2011-05-11 11:29:12 PDT
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!

Note You need to log in before you can comment on or make changes to this bug.