309988 - Firefox and Thunderbird can't print

Status: RESOLVED FIXED

(Core :: Printing: Output, defect)

Description

[Andrew Benton]

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

When I try to print a page with Firefox or an email in Thunderbird, nothing
happens for about a minute then the printer whirs and pulls a piece of paper
through without printing on it. I have a build of firefox from the 28th of
August that can print OK and a build of Thunderbird from the 3rd of sept that
can print fine. All the recent builds I've tried can't print. During the minute
before the printer whirs, if I check the gnome system monitor, cpu use is
running at about 50%. Printing works fine with all other applications (Abiword,
Gedit, OpenOffice,xpdf). If I print to a file it doesn't take a minute and it
doesn't use cpu cycles, but the .ps file it creates is blank

Reproducible: Always

Steps to Reproduce:
1.try to print
2.
3.

Actual Results:  
Zarro printing

Expected Results:  
printed

Comment 1

[Andrew Schultz]

I get a blank page printing http://www.mozilla.org/ to a ps file with linux
seamonkey trunk 2005092505.  This regressed between linux seamonkey trunk builds
2005091703 and 2005091805 (bug 307404).

Comment 2

[Ilja Sekler]

Printing WFM fine both in Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1)
Gecko/20050925 Firefox/1.6a1 (official build) and, for example, in the
2005-09-24 nightly. Can't reproduce the bug.

Comment 3

[Ilja Sekler]

Oh, I see: can't print in a new profile with default settings; open the printer
settings dialog, change the paper size - printing works from now on.

Comment 4

[Andrew Benton]

Confirmed. Yes, it works if I change the paper size. I've never needed to alter
that before. Thanks for the workaround

Comment 5

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

Attachment: proposed fix

The relevant diff in prefs.js for a new profile before/after opening printer
properties is this one for me:

-user_pref("print.printer_CUPS/LaserJet-1100.print_paper_height", "279,40");
+user_pref("print.printer_CUPS/LaserJet-1100.print_paper_height", " 10,98");
-user_pref("print.printer_CUPS/LaserJet-1100.print_paper_size", 0);
+user_pref("print.printer_CUPS/LaserJet-1100.print_paper_size", 666);
-user_pref("print.printer_CUPS/LaserJet-1100.print_paper_width", "215,90");
+user_pref("print.printer_CUPS/LaserJet-1100.print_paper_width", "  8,46");

This looks like width/height are specified in mm but thought to be in in. The
attached patch fixes the problem for me.
The "print.print_paper_size_unit" setting alone seems to fix it *for me* on a
new profile, but setting the default w/h/name too seems safer to me.

Comment 6

[Kenneth Herron]

I was able to reproduce this yesterday too. In the postscript output, the paper
height & width were set to ridiculously large values. This can cause print
failure, if the print job requests a paper size that the printer doesn't have. I
was able to "fix" this by opening the printer properties dialog.

We've had other bug reports like this, suggesting that some critical
initialization doesn't happen unless the user opens the printer properties
dialog. This is the "underlying bug" I was referring to in bug 272670 comment 18.

In my case, after "fixing" the page size data (by rerunning the print job, or
hand-editing the postscript output), I was still getting errors from ghostscript
while reading font data. So it's possible that there's another problem at work here.

Comment 7

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

(In reply to comment #6)
> I was able to reproduce this yesterday too. In the postscript output, the paper
> height & width were set to ridiculously large values.
I'm seeing that too without the above patch, and the factor to the right value
for the paper named is about 25.4, which led to my analysis above :)

Who's the right reviewer for this patch?

Comment 8

[Kenneth Herron]

I don't think that patch is the right way to go. It's possible that it prevents
the problem, but the print dialog is supposed to get its paper sizes from the
printing subsystem. We've never had to embed paper sizes into all.js before and
it  shouldn't be necessary now.

Comment 9

[Andrew Benton]

The patch in comment #5 doesn't work for me. I applied it, rebuilt Firefox and
with a clean profile I was unable to print. Simply opening the print properties
dialog is enough to fix the problem, even if I don't change any of the settings.
It's like Kenneth says in comment #6, something doesn't seem to get initalised
properly unless you open the print properties dialog.

Comment 10

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

Attachment: fix

The problem was that in nsDeviceContextSpecG.cpp, 
nsPrinterEnumeratorGTK::InitPrintSettingsFromPrinter sets the default paper
size in mm but sets the size unit according to the paper's IsMetric property,
so we get the mm sizes interpreted as in. That was no problem previously since
the real printing code again used the nsPaperPS code to get the size from the
name but after the patch from bug 307404 that's not true anymore.

Comment 11

[Andrew Benton]

The new patch also doesn't work. I've just applied it and rebuilt firefox. If I
use that build to create a new profile it can't print. Unless I open the Printer
Properties dialog, then it will work, just like a normal trunk build

Comment 12

[Kenneth Herron]

Comment on attachment 198467 [details] [diff] [review]
fix

This fixes the problem as far as I can reproduce it. With the fix in place, the
paper size is set correctly for a brand-new profile. We need an xlib version
though; the file xlib/nsDeviceContextSpecXlib.cpp is the file to patch, and
it's virtually identical to the GTK version.

Having said that, if it doesn't fix Andrew's problem, then maybe he's
encountering a different problem.

Comment 13

[Kenneth Herron]

Andrew, you said you have a copy of firefox with the second patch applied. I'd
like to get copies of the print output you say still doesn't work. Could you go
through the steps to reproduce this again, only this time print to a pair of
files  (one non-working, one working)? Once you have those, please email them to me.

Comment 14

[Andrew Benton]

My bad. Mea culpa. I must have screwed up somewhere applying the patch. I've
just done it again and this build works with a clean profile. Sorry Christian

Comment 15

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

Attachment: also patch nsDeviceContextSpecXlib

Also patch nsDeviceContextSpecXlib.cpp.

Comment 16

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 199284 [details] [diff] [review]
also patch nsDeviceContextSpecXlib

is this a problem on the FF branch? If it is, we need to get branch approval
quick

Comment 17

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

(In reply to comment #16)
> (From update of attachment 199284 [details] [diff] [review] [edit])
> is this a problem on the FF branch? If it is, we need to get branch approval
> quick
> 

No, this ist trunk only since bug 307404 has landed in trunk only (yet).

Comment 18

[Jo¾e Klepec]

The last konown build I know of functional printing was from 20050913 (13. Sep
2005). I updated after that one on 20051001 and had small problems which
resulted in 20051010 to be a blank page. Since I tested quite a lot of builds
both en-US and sl, more or less without success. Mozilla/5.0 (X11; U; Linux
i686; sl; rv:1.9a1) Gecko/20051018 Firefox/1.6a1 ID:2005101809, TB day earlier. 

Similar bug is: #312925, but they claim it's a Fedora core problem which I don't
think so - I'd have problems lots before that.

Reproducible is: always, from the bar, menu, (news) message, text or HTML, any
kind of webpage, no matter of fonts, characters, javascript and such stuff.
Printng otherwise from applications works normal (cups).
 
I presume that TB/FF just send a Form Feed character or worse, they reset print
buffer before last Form Feed. That would explain blank .ps file.

Comment 19

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

Comment on attachment 199284 [details] [diff] [review]
also patch nsDeviceContextSpecXlib

kherron: I don't have cvs access, could you check this in?

Comment 20

[Kenneth Herron]

Checked in:

Checking in gtk/nsDeviceContextSpecG.cpp;
/cvsroot/mozilla/gfx/src/gtk/nsDeviceContextSpecG.cpp,v  <-- 
nsDeviceContextSpecG.cpp
new revision: 1.68; previous revision: 1.67
done
Checking in xlib/nsDeviceContextSpecXlib.cpp;
/cvsroot/mozilla/gfx/src/xlib/nsDeviceContextSpecXlib.cpp,v  <-- 
nsDeviceContextSpecXlib.cpp
new revision: 1.49; previous revision: 1.48
done

Thanks, Christian!

Comment 21

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

So it seems that I needed to remove all the print.* prefs from my profile's prefs.js in order to get printing to work again after this bug was fixed.  Was permanent damage to user preferences expected?  Can it be cleaned up easily?

Comment 22

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

(In reply to comment #21)
> So it seems that I needed to remove all the print.* prefs from my profile's
> prefs.js in order to get printing to work again after this bug was fixed.  Was
> permanent damage to user preferences expected?  Can it be cleaned up easily?

No profile damage was expected, no. And I cannot reproduce: I created a profile on ff 1.0.x, printed, then started trunk with that profile, printed still fine without remove the print.* prefs.