652929 - First printed page is blank (aside from header/footer), despite being fine in Print Preview, on itmanagement.earthweb.com articles

Status: RESOLVED FIXED

(Core :: Printing: Output, defect)

Description

[Nick]

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

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

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

Attachment: 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]

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

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]

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]

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]

Attachment: 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]

Attachment: pdf printout from testcase

on Firefox 4.0.1 on Ubuntu

Comment 10

[Daniel Holbert [:dholbert]]

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

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

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]

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

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

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

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

Don't we trigger that assertion when we print almost anything?

Comment 18

[Daniel Holbert [:dholbert]]

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]

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

(sorry, somehow the resolution accidentally got changed on my last comment)

Comment 21

[Daniel Holbert [:dholbert]]

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!