First printed page is blank (aside from header/footer), despite being fine in Print Preview, on articles




8 years ago
8 years ago


(Reporter: nrundy, Unassigned)


(Blocks 1 bug, {regression, testcase})

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)




(3 attachments)



8 years ago
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 and  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"

Actual Results:  
only page 2 prints

Expected Results:  
page 1 and 2 will both print


8 years ago
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.)

Comment 2

8 years ago
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.)
Posted file 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
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 articles
Version: 2.0 Branch → Trunk
Blocks: 521204
Ever confirmed: true

Comment 4

8 years ago
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.
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

8 years ago
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

8 years ago
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.
Keywords: regression, testcase

Comment 8

8 years ago
Posted file 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

8 years ago
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:

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.
Last Resolved: 8 years ago
Depends on: 652178
Resolution: --- → WORKSFORME

Comment 13

8 years ago
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

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

Comment 19

8 years ago
(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.)
Ever confirmed: false
Resolution: FIXED → ---

Comment 20

8 years ago
(sorry, somehow the resolution accidentally got changed on my last comment)
Last Resolved: 8 years ago8 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.