315687 - "print" prints blank pages (regression)

Status: RESOLVED FIXED

(Core :: Printing: Output, defect)

Description

[Deomid Ryabkov]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20050918 Firefox/1.6a1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20050918 Firefox/1.6a1

a regression that has happened between 20050917 and 20050918 causes firefox and thunderbird to print blank pages.
preview works fine, the print job is sent to printer, but the page comes out blank.
this is still valid for latest firefox/thunderbird nightly.

Reproducible: Always

Steps to Reproduce:
1. send a page to printer.
Actual Results:  
blank page comes out of the printer


as i said, i pinned down the regression to the update from 20050917 to 20050918.
20050917 prints the page content, 20050918 prints blank pages.
btw, the page count is correct - if you print more than one page, the right number of blank pages come out.

i use CUPS for printing from Linux to a printer attached to windows workstation over SMB.

Comment 1

[Steve England [:stevee]]

Bonsia range:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-09-17&maxdate=2005-09-18&cvsroot=%2Fcvsroot

Regression from bug 307404 mayhap?

Comment 2

[Christian Persch (GNOME) (away; not receiving bug mail)]

Could you print a blank page to file and attach the .ps here?

After that, can you try if the workaround from bug 309988 comment 3 fixes the problem?

Comment 3

[Deomid Ryabkov]

Attachment: test file being printed

Comment 4

[Deomid Ryabkov]

Attachment: postscript rendering

Comment 5

[Deomid Ryabkov]

yes, the workaround fixes the problem.
simply opening printer properties and hitting ok is enough.
from that point on, that is not required, and printing works fine.
looks as if some new setting not being assigned a default value and saving settings explicitly fixes that.

Comment 6

[Andrew Schultz]

confirmed with linux seamonkey trunk 20051110.  you need old prefs (from a build before bug 307404) to reproduce this.

Comment 7

[Tomas Nordström]

*** Bug 320391 has been marked as a duplicate of this bug. ***

Comment 8

[Ian Neal]

Does this still happen after the landing of the patch on bug 324072?

Comment 9

[Myk Melez [:myk] [@mykmelez]]

(In reply to comment #8)
> Does this still happen after the landing of the patch on bug 324072?

Yes, this is still happening.  I ran into it after switching from Firefox 2 nightlies to trunk nightlies about a month ago.  The workaround from comment 5 of opening the Printer Properties dialog and then clicking OK worked for me.

I then compared my prefs.js file from before and after applying the workaround and found the following changes:

+user_pref("print.printer_CUPS/scopier.print_edge_bottom", 4);
+user_pref("print.printer_CUPS/scopier.print_edge_left", 4);
+user_pref("print.printer_CUPS/scopier.print_edge_right", 4);
+user_pref("print.printer_CUPS/scopier.print_edge_top", 4);

-user_pref("print.printer_CUPS/scopier.print_paper_height", "279.40");
+user_pref("print.printer_CUPS/scopier.print_paper_height", " 10.98");

-user_pref("print.printer_CUPS/scopier.print_paper_size", 0);
+user_pref("print.printer_CUPS/scopier.print_paper_size", 666);

-user_pref("print.printer_CUPS/scopier.print_paper_width", "215.90");
+user_pref("print.printer_CUPS/scopier.print_paper_width", "  8.46");

One or more of these entries, then, works around the problem.  But given that the entries are all printer-specific, presumably they only work around the problem for a single printer.

Comment 11

[Kenneth Herron]

Attachment: Patch v1

This adds a sanity check when loading the paper size prefs. If the unit flag is set to inches, then ignore the saved size if height or width is > 100 (8 ft 4 in).

I also changed the pref load/save code to handle all of the paper size prefs as a group under control of a single load/save flag. I did this so there would be a place to insert the sanity check. Loading or saving some of the size prefs without the others doesn't make sense anyway.

I also removed an obsolete and unused nsIPrintSettings attribute "paperSize". This was supposed to be the subject of bug 382167, but I wanted to repurpose that attribute's load/save flag to control loading/saving the group of paper size prefs.

Comment 12

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Comment on attachment 271661 [details] [diff] [review]
Patch v1

Looks ok to me, would like Stuart to take a look as well though since he knows this code better than I do.

Comment 13

[Kenneth Herron]

I attempted to check in yesterday (7/14), but the two firefox win32 unit test systems started failing unit tests so I had to back out. Filed bug 388169 about the fact that changing the uuid for nsIPrintSettings.idl causes unit tests to fail.

I attempted to check in again this morning and also touched the firefox win32 clobber file. The printing unit tests passsed on qm-winxp01 but still failed on qm-win2k3-01. It doesn't appear from the logs that the clobber file was honored; Gavin Sharp opened bug 388223 about that. I backed out again.

Comment 15

[Kenneth Herron]

Comment on attachment 271661 [details] [diff] [review]
Patch v1

Requesting approval to check in. This addresses a printing issue on unix that will be experienced by people upgrading to FF 3.x. Gecko 1.8 stored the paper size of the last print operation incorrectly, and gecko 1.9 will interpret the size as 25.4x as large as it should be.

Comment 16

[Kenneth Herron]

Finally checked in. Resolving FIXED.

Comment 17

[Boris Zbarsky [:bzbarsky]]

This change made it impossible to print or preview for anyone upgrading from 1.8 (or a 2007-08-26 trunk build, for that matter).  See bug 394407.

Comment 18

[Boris Zbarsky [:bzbarsky]]

Please ignore comment 17; I had the wrong culprit.

Comment 19

[Boris Zbarsky [:bzbarsky]]

Though the comments in bug 394407 about issues with this patch still apply.

Comment 20

[Martijn Wargers (dead)]

(In reply to comment #19)
> Though the comments in bug 394407 about issues with this patch still apply.

So a new bug should be filed about that, right? (I would do it, if I would understand what you mean)

Comment 21

[Kenneth Herron]

Reopening. You're right, the sense of that test is backwards, so this bug isn't fixed.

Comment 22

[Kenneth Herron]

I checked in a change to reverse the sense of that test. Resolving FIXED again.

Comment 23

[Boris Zbarsky [:bzbarsky]]

So if width is 1 and height is 200 you want to treat that as success?