272670 - unexpected error "paper size is not supported by your printer" printing to Postscript/default

Status: RESOLVED FIXED

(Core :: Printing: Output, defect)

Description

[Max Alekseyev]

Mozilla Linux build 2004120106

This bug seems to be introduced in recent nighties.

To reproduce:
1. Open any page
2. Try to print it using "Postscript/default" printer
3. Get an error "There was a problem printing because the paper size you
specified is not supported by your printer"

Comment 1

[Kenneth Herron]

This wouldn't be an Xprint bug.

Max, what paper size do you have selected? Open file->print and click on the
"Properties" button.

Comment 2

[Max Alekseyev]

The paper size is Letter which coincides with the CUPS printer driver settings.
Actually I did not touch these settings for a long time so it not an issue of
misconfiguration. Moreover, there are no printing problems in other applications.

Comment 3

[Kenneth Herron]

I downloaded the 2004120106 linux build and tried to reproduce the bug here, but
the build worked properly for me.

Given the way paper sizes are handled in the PS module, it's plausible that the
printing code was getting an invalid paper size from the print dialog. I don't
think any of the relevant PS code has been changed lately, but there's currently
a lot of activity going on to merge various changes from the recent firefox
release back into the mozilla trunk.

Max, the first thing you might try is to download a newer nightly build and see
if the problem still occurs. If the problem persists, you could try creating a
new profile and seeing if that works correctly.

Comment 4

[Kenneth Herron]

Max, are you still experiencing this problem? Have you tried the suggestions
from comment 3?

Comment 5

[Max Alekseyev]

I don't see the bug anymore.

Comment 6

[Max Alekseyev]

The bug strikes back.
Now I see with Mozilla linux build 20050526

Comment 7

[Lorenzo Colitti]

I see this too, in Deer Park alpha 1 on Linux using CUPS.

I can't print anything at all, and I haven't been able to for a long time (every
trunk build I've used in recent weeks suffers from this problem).

Comment 8

[Lorenzo Colitti]

I fixed this by blowing away all the "print.*" preferences in prefs.js.

I had over 100 kB of these prefs! Now they are gone, printing works fine for me
again.

Comment 9

[Kenneth Herron]

Bug 295676 appears to be the same issue. That reporter also solved his problem
by cleaning up old preferences.

Lorenzo, if you still have an old copy of your preferences, I'd like to get a
copy of them. I'd like to figure out what prefs are causing this.

Max, if you're still experiencing this, could you provide the print-related
preferences from your profile?

Comment 10

[Max Alekseyev]

Attachment: bad print.* settings

grep print. prefs.js >prefs.txt

My print.* settings

Comment 11

[Max Alekseyev]

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

Comment 12

[Max Alekseyev]

I confirm that wiping out all print.* settings resolves the problem. But
according to my experience it can easily reappear later.

Comment 13

[Max Alekseyev]

Ops. It's back. Less than two weeks of printing and I'm forced to wipe out my
print.* settings again.

Comment 14

[Max Alekseyev]

Attachment: Testcase

It seems to be ONLOAD="window.print()" who causes the bug.

To reproduce:
1. Open provided Testcase
2. Follow step 2 in the original comment 0

Comment 15

[Andrew Schultz]

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

Comment 16

[Andreas Lange]

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

Comment 17

[Ilja Sekler]

The printing after onload="window.print()" works now as desired. The bug seems
to be fixed due to the fix of 307404.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20050917 Firefox/1.6a1
checkout start: Sa Sep 17 23:37:04 CEST 2005

Comment 18

[Kenneth Herron]

The paper size error is evidence that the printing module isn't getting a valid
paper size name from the print dialog. The fix for bug 307404 probably "fixed"
this by avoiding a search based on this name, but we probably still have the
underlying problem.

According to bonsai, some aviary changes to the print dialog code were merged on
2004-11-30. That's about the right time to cause this problem.

Comment 19

[Andrew Schultz]

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

Comment 20

[Andreas Lange]

(In reply to comment #18)
> The paper size error is evidence that the printing module isn't getting a valid
> paper size name from the print dialog. The fix for bug 307404 probably "fixed"
> this by avoiding a search based on this name, but we probably still have the
> underlying problem.
> 
> According to bonsai, some aviary changes to the print dialog code were merged on
> 2004-11-30. That's about the right time to cause this problem.

Since we have this problem on the branch too, should someone file a new bug and
try to find the underlying problem, or should the fix in bug 307404 be nominated
for 1.8b5?

Comment 21

[Ilja Sekler]

This bug has been shipped into the Firefox 1.5 release and remains also in the actual nightly builds for the 1.8 branch.

Comment 22

[Eric L.]

Hello,

as documented in http://bugs.debian.org/344401 I've discovered other issues, IMHO related to the behavior described here. Summarizing:

> I have only one printer, but it shows 3 times under different "systems":
> - xprint, named smthing@64 + the xp_pdf/ps queues, with a print
>   properties dialog allowing setup of the job name + 4 dropdowns + color
>   + fonts + margins.
> - CUPS, named CUPS/smthing, with very basic properties where I can only
>   setup the paper size, color/gray and margins.
> - PS, named Postscript/Default, with same properties as CUPS + the
>   possibility to enter a command line.
> 
> In addition to the other comments already made, I noticed that once I've
> printed out to one system, all other systems switch their property dialog
> to the one of the 1st used system. That doesn't sound good.
> 
> Also, if my 1st print goes to CUPS or PS, the print preview window
> looses all the page setup options at the top (only "Page n of N" and the
> "Close" button do remain). This problem doesn't appear if xprint is the
> chosen system.

So, wouldn't it make sense to re-open the bug and, as another poster suggested, to check for the root cause of the issue?

Thanks, Eric

Comment 23

[Kenneth Herron]

(In reply to comment #22)

> > I have only one printer, but it shows 3 times under different "systems":
> > - xprint, named smthing@64 + the xp_pdf/ps queues, with a print
> >   properties dialog allowing setup of the job name + 4 dropdowns + color
> >   + fonts + margins.
> > - CUPS, named CUPS/smthing, with very basic properties where I can only
> >   setup the paper size, color/gray and margins.
> > - PS, named Postscript/Default, with same properties as CUPS + the
> >   possibility to enter a command line.

The user can set preferences to disable the PS module's CUPS support or the entire PS module. See <http://kb.mozillazine.org/About:config_entries>, the section for print.*.

> > In addition to the other comments already made, I noticed that once I've
> > printed out to one system, all other systems switch their property dialog
> > to the one of the 1st used system. That doesn't sound good.

I believe this is bug 324072. Basically, FF is showing the printer properties dialog for the printer that was used last, not the currently selected printer. That bug was fixed on the trunk and on the gecko 1.8.1 branch (which is for firefox 2.0) but not on the gecko 1.8.0 branch (FF 1.5).

In fact I think bug 324072 is the explanation for the first comment on <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=344401>.

> So, wouldn't it make sense to re-open the bug and, as another poster suggested,
> to check for the root cause of the issue?

I resolved this bug as fixed because the specific issue in comment 0 was fixed on the trunk, which is the usual criteria for closing a bug. You can see that the fix for bug 307404 was never committed to any branch, in part because it uncovered another bug (bug 309988).

I suspect the "underlying issue" causing the paper size complaint is that the paper size for the last print job is being used as the default size for the next job, even if the size isn't valid for the current printer. This would only be a problem on systems using XPrint. The PS module has an internal paper size list and considers all sizes valid for all printers.

I have no objection to seeing these things fixed in the FF 1.5 series. But unfortunately I have almost no time to spend on mozilla for the foreseeable future, so someone else will have to step up and do the work.