Closed Bug 315687 Opened 16 years ago Closed 14 years ago

"print" prints blank pages (regression)

Categories

(Core :: Printing: Output, defect)

x86
Linux
defect
Not set
major

Tracking

()

RESOLVED FIXED

People

(Reporter: myself, Assigned: kherron+mozilla)

References

(Depends on 1 open bug)

Details

(Keywords: qawanted, regression)

Attachments

(3 files)

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.
Component: General → Printing
Keywords: regression
Product: Firefox → Core
Version: unspecified → Trunk
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?
Depends on: 307404
Attached file postscript rendering
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.
Assignee: nobody → printing
QA Contact: general
confirmed with linux seamonkey trunk 20051110.  you need old prefs (from a build before bug 307404) to reproduce this.
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 320391 has been marked as a duplicate of this bug. ***
Does this still happen after the landing of the patch on bug 324072?
Keywords: qawanted
(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.
Duplicate of this bug: 381848
Blocks: 382167
Attached patch Patch v1Splinter Review
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.
Assignee: printing → kherron+mozilla
Status: NEW → ASSIGNED
Attachment #271661 - Flags: review?(vladimir)
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.
Attachment #271661 - Flags: superreview?(pavlov)
Attachment #271661 - Flags: review?(vladimir)
Attachment #271661 - Flags: review+
Attachment #271661 - Flags: superreview?(pavlov) → superreview+
Depends on: 388169
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.
Duplicate of this bug: 316144
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.
Attachment #271661 - Flags: approval1.9?
Flags: blocking1.9?
Attachment #271661 - Flags: approval1.9? → approval1.9+
Finally checked in. Resolving FIXED.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Flags: blocking1.9?
Resolution: --- → FIXED
Depends on: 394407
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.
Please ignore comment 17; I had the wrong culprit.
Though the comments in bug 394407 about issues with this patch still apply.
No longer depends on: 394407
(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)
Reopening. You're right, the sense of that test is backwards, so this bug isn't fixed.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
I checked in a change to reverse the sense of that test. Resolving FIXED again.
Status: REOPENED → RESOLVED
Closed: 14 years ago14 years ago
Resolution: --- → FIXED
So if width is 1 and height is 200 you want to treat that as success?

Flags: in-testsuite?
You need to log in before you can comment on or make changes to this bug.