printing in Firefox 3 Beta 3 is broken

[Dave Morley]

Binary package hint: firefox-3.0

Printing has stopped functioning in FF3 beta 3. If you hit the print option in FireFox it seem to send the file to the print queue but then in the print queue it say print stopped and doesn't print anything.

This is the Cups error log

E [22/Feb/2008:21:01:17 +0100] [Job 25] pdftops-options: -cfg /etc/cups/pdftops.conf
E [22/Feb/2008:21:01:17 +0100] [Job 25] /usr/bin/pdftops exited with exit code 1
E [22/Feb/2008:21:01:17 +0100] PID 1247 (/usr/lib/cups/filter/pdftops) stopped with status 1!
E [22/Feb/2008:21:01:17 +0100] [Job 25] Empty print file!
E [22/Feb/2008:21:01:17 +0100] PID 1249 (/usr/lib/cups/filter/pstops) stopped with status 1!
E [22/Feb/2008:21:01:18 +0100] PID 1251 (/usr/lib/cups/filter/rastertospl2) stopped with status 1!
E [22/Feb/2008:21:01:19 +0100] PID 1252 (/usr/lib/cups/backend/ipp) stopped with status 1!

[FredBezies (fredbezies-deactivatedaccount)]

It is a major bug for linux user with HP printers... And there are a lot of them ;)

[Ventnor-bugzilla (ventnor-bugzilla)]

Weird, we have a HP printer in the NZ office and it seems to work perfectly. Can anyone else reproduce this?

[FredBezies (fredbezies-deactivatedaccount)]

Which version of HP-Lip do you have ? Which HP ?

I have HPLip 2.7.10 and a PSC3180 printer (all-in-one) hardware.

[Roc-ocallahan (roc-ocallahan)]

Can you print using other GTK apps that use the GTK print dialog?

[FredBezies (fredbezies-deactivatedaccount)]

Of course, I can. For example with gedit, or epiphany web browser.

And no errors in error console :(

This makes me really sad !

[FredBezies (fredbezies-deactivatedaccount)]

Created attachment 299765
screenshot of error.

Here is what I got while trying to print using firefox trunk version.

[FredBezies (fredbezies-deactivatedaccount)]

Printing works with HP-Toolbox 2.7.7 on Ubuntu 7.10.

Doesn't HP-Toolbox 2.7.10+ on ArchLinux.

What could block on 2.7.8 / 2.7.9 release version ?!

http://hplip.sourceforge.net/release_notes.html

Editing title.

[Roc-ocallahan (roc-ocallahan)]

If you print to PDF and then print that PDF, does that work?

[FredBezies (fredbezies-deactivatedaccount)]

yes. But it is not a great way to get a page printed.

[FredBezies (fredbezies-deactivatedaccount)]

I think Cups WebUI gave me the answer.

Number of pages to be print are not sent to cups which is used by HPLip which drives the printer.

When I used Epiphany to print google home page, I got this in task page of CUPS WebUI (tasks tab) :

Photosmart_C3100-42 Google fred 245ko 1 canceled on
wed 30 jan 2008 18:05:03 CET

But with firefox trunk build and trying to print this page :

Photosmart_C3100-43 Bug 414314 – SInce landing of bug 193001, I cannot get a print to be done with HP-Toolbox 2.7.10 fred 126ko Unknown stopped

Will added screenshots (I translated error message from french).

So, what do you think of that possibility ?

[FredBezies (fredbezies-deactivatedaccount)]

Created attachment 300393
screenshot of cups webui showing the "unknown number of pages".

Could it explain the stopped task in hlplip ?!

[FredBezies (fredbezies-deactivatedaccount)]

I wonder also if it is a 64 bits bug only. It could be a really bad thing :(

[Ventnor-bugzilla (ventnor-bugzilla)]

I can't really explain that, all we do is generate a temp PS or PDF and attach that to a GTK Print job, then send it. GTK takes care of the rest. This could be a GTK bug...

[FredBezies (fredbezies-deactivatedaccount)]

So, why does printing work with another "classic" gtk based applications, like Gedit ? Or With Epiphany ? Which both use gnome printing tools ?!

Maybe my compilation settings ?!

I'm completely lost here.

Here is my .mozconfig, if it could help :

#
# See http://www.mozilla.org/build/ for build instructions.
#

. $topsrcdir/browser/config/mozconfig

# Options for 'configure' (same as command-line options).
ac_add_options --enable-optimize="-Os -march=athlon64 -w -pipe"
ac_add_options --disable-debug
ac_add_options --disable-tests
ac_add_options --enable-default-toolkit=cairo-gtk2
ac_add_options --enable-strip
ac_add_options --disable-mochitest

[Jwalden+bmo (jwalden+bmo)]

(In reply to comment #14)
> So, why does printing work with another "classic" gtk based applications, like
> Gedit ? Or With Epiphany ? Which both use gnome printing tools ?!
>
> Maybe my compilation settings ?!

With all due respect, please recognize people are trying to solve the problem. They're trying to work with you to figure out what's wrong. Writing with an overly shrill voice, an accusatory tone insinuating that you think the people trying to figure out the problem here don't believe you, and, if you'll forgive me saying so, an excessive number of exclamation marks, won't help your position.

Also -- hey -- it's beta, bleeding-edge software. Things won't always work. But in the end, the big problems like not being able to print get fixed. If it's really that big a deal, drop back a few builds for daily use until this is fixed, and only keep an affected build around for use in diagnosing this problem.

[FredBezies (fredbezies-deactivatedaccount)]

With all the respect I have to give to you, I'm using trunk builds since year 2000.

I know it is beta software. I know it could be broken. Don't treat me like an idiot, thanks !

I'm just try to show that I don't understand why there is this bug.

So, if I can, just close it as invalid, as it looks like it is not a mozilla code bug but a gtk one.

Have a good day. I want to ask how to have my account deleted.

Thanks !

[Bugzilla-tuxmachine (bugzilla-tuxmachine)]

(In reply to comment #16)
> Have a good day. I want to ask how to have my account deleted.
You can't, but can change your password to some junk you'll never remember and be sure not to keep a copy laying around. (/dev/random+creativity)

[FredBezies (fredbezies-deactivatedaccount)]

What a pity.

Jeff is right, but as I am using a 64 bits linux, I cannot drop any builds, because there is no official 64 bits nightly :(

Reopening bug closed because I have closed it by anger.

If only there could be official 64 bits nightlies, it could help 64 bits linux users :(

[Roc-ocallahan (roc-ocallahan)]

Karl uses 64-bit builds, he may be able to reproduce the problem.

[FredBezies (fredbezies-deactivatedaccount)]

Let's hope so.

I'm grabbing a debian etch 64 bits right now in order to test an homemade build in it, in order to be sure this is not an arch linux only bug :)

[Karlt (karlt)]

Created attachment 300759
cups error log

I seem to have the same issue with my Epson.

The job is spooled fine but fails in foomatic-rip.

Printing to file the using lpr or evince with gnome-print works fine.

[Karlt (karlt)]

print_job: auto-typing file...
print_job: request file type is application/pdf.

Do we submit a pdf?

[Karlt (karlt)]

Created attachment 300761
foomatic-rip.log

failure in ghostscript:

Unrecoverable error: configurationerror in setpagedevice
Operand stack:
    true --nostringval--

/tmp/foomatic-rip.ps from turning on debug in foomatic-rip views fine.

[Ventnor-bugzilla (ventnor-bugzilla)]

(In reply to comment #22)
> print_job: auto-typing file...
> print_job: request file type is application/pdf.
>
> Do we submit a pdf?
>

We submit a PDF if GTK says that your printer supports PDF.

[FredBezies (fredbezies-deactivatedaccount)]

Why a pdf ? Is this the key of the problem ?!

Very strange :(

Ah, 64 bits OS pleasure ;)

[Karlt (karlt)]

Printing works for me if I change the following lines in the printer ppd file from

*FoomaticRIPOptionSetting PageSize=Custom: " -dDEVICEWIDTHPOINTS=0 -dD&&
EVICEHEIGHTPOINTS=0"

to

*FoomaticRIPOptionSetting PageSize=Custom: ""

[Bill-wg9s (bill-wg9s)]

(In reply to comment #26)
> Printing works for me if I change the following lines in the printer ppd file
> from
>
> *FoomaticRIPOptionSetting PageSize=Custom: " -dDEVICEWIDTHPOINTS=0 -dD&&
> EVICEHEIGHTPOINTS=0"
>
> to
>
> *FoomaticRIPOptionSetting PageSize=Custom: ""
>

This "fixed" the issue for me as well.

[Bill-wg9s (bill-wg9s)]

Oh, and by the way, this is NOT a 64-bit build only issue.

It might be 64-bit OS only though.

I cannot print with the official 32-bit Linux nightlies on my 64-bit Linux system without the ppd file hack.

[FredBezies (fredbezies-deactivatedaccount)]

Which is a "bad" thing to do...

Well, as I don't want to hack my ppd file, I think I will use Epiphany (gecko 1.8.1.xx based) as long as it is supported by my distro when I need to print a web page.

There is no workaround this "bug" that can be added to trunk code ?!

/me is disappointed :(

[Bill-wg9s (bill-wg9s)]

The change to preferring PDF if the printer supports it, does not appear to be the cause of the issue. I backed that part of the change out hoping it would be a workaround, but it had no effect on this bug (although it did fix bug 415425).

[Bill-wg9s (bill-wg9s)]

Unfortunately, the landing of the code for bug 406376 and bug 415425 has not fixed this issue.

[Karlt (karlt)]

I get the same error with lpr and Custom media sizes.

lpr -P HP_Officejet_5600_series_USB_1 -o media=Custom.8.5x11.0in /usr/share/doc/groff-1.19.2-r1/examples/mom/letter.ps

foomatic-filters-3.0.20060720, gimp-print-4.2.7, ghostscript-gpl-8.61-r1 on amd64 Gentoo.

It seems that the only reason why this is showing up more in Mozilla is that Mozilla treats even standard page sizes as Custom.

Same issue when transferring the postscript file from foomatic-rip on the amd64 to use ijsgutenprint-5.0.1-Oubuntu8 on i686.

DEBUG: ijsgutenprint: gutenprint_set_cb: PaperSize='0x0'
DEBUG: ijsgutenprint: paper size 0.000000 0.000000 0x0
DEBUG: ijsgutenprint: Found page size Custom
DEBUG: ijsgutenprint: gutenprint_get_cb: PrintableArea
DEBUG: ijsgutenprint: PrintableArea 783 594 8.25x10.875
DEBUG: ijsgutenprint: gutenprint_get_cb: PrintableTopLeft
DEBUG: ijsgutenprint: PrintableTopLeft 0 9 0.125x0
DEBUG: ijsgutenprint: gutenprint_set_cb: TopLeft='0.125x0'
DEBUG: ijsgutenprint ppd_mode 0 top left: 0.125x0
DEBUG: ijsgutenprint: l 9 r 603 t 0 b 783 pw 612 ph 792
DEBUG: ijsgutenprint: left top 9.000000 0.000000 9 0 0.125x0
DEBUG: ijsgutenprint: gutenprint_enum_cb: key=ColorSpace
Unrecoverable error: configurationerror in setpagedevice
Operand stack:
    true --nostringval--

[Bill-wg9s (bill-wg9s)]

This bug should probably be resolved as INVALID.

This is NOT a Mozilla issue. It is a bug in the foomatic-filters.

I fixed the issue by installing the latest version of foomatic-filters available here:

http://www.linux-foundation.org/en/OpenPrinting/Database/Foomatic#Full_download

[Jwalden+bmo (jwalden+bmo)]

Assuming other people can confirm this, we should relnote this. To whoever confirms a foomatic-filters upgrade solves the problem, please add the relnote keyword here?

[Kairo-kairo (kairo-kairo)]

This _is_ a Mozilla problem, as it works with all kinds of other software that tries to print. We have no setting whatsoever of a page size, and that makes us send print jobs with really bogus pages sizes with some ppds. This also happens with all ppds I have for my Canon ip4000 printer, including those Canon Japan published for those printers, and which works for KDE apps, Acrobat Reader and all others I tried so far.

[Bill-wg9s (bill-wg9s)]

(In reply to comment #35)
> This _is_ a Mozilla problem, as it works with all kinds of other software that
> tries to print. We have no setting whatsoever of a page size, and that makes us
> send print jobs with really bogus pages sizes with some ppds. This also happens
> with all ppds I have for my Canon ip4000 printer, including those Canon Japan
> published for those printers, and which works for KDE apps, Acrobat Reader and
> all others I tried so far.
>
Please see comment #32.

[Bill-wg9s (bill-wg9s)]

(In reply to comment #35)
> This _is_ a Mozilla problem, as it works with all kinds of other software that
> tries to print. We have no setting whatsoever of a page size, and that makes us
> send print jobs with really bogus pages sizes with some ppds. This also happens
> with all ppds I have for my Canon ip4000 printer, including those Canon Japan
> published for those printers, and which works for KDE apps, Acrobat Reader and
> all others I tried so far.
>

Well, I suppose that Mozilla is now always specifying a custom page size even when unnecessary make the bug occur all the time when it really does not need to, so a bug could be filed on that issue.

But even with that fixed, printing will still not work for ANY (not just Mozilla) application when a custom page size is actually required, without the foomatic-filter fix.

[Kairo-kairo (kairo-kairo)]

And we don't even give the user any possibility to chose the page size, which is also wrong, btw.

Anyways, it's clearly a bug if we can't print with the same printer that other apps can print fine with, and even builds before that (sorry to say that) crappy new print dialog can print fine with.

[Kairo-kairo (kairo-kairo)]

And if I understand it correctly, this bug is about the inability to print to printers (with ppds) that other apps can print to fine, so whatever the fix is, this bug is where it should be made.
If there is a theoretical bug in some ppds that won't work with ANY application, that's something different, but this bug is about the same ppd working with older builds and other applcations but NOT with current Mozilla trunk builds tht have the new gnomeized print dialog.

[Bill-wg9s (bill-wg9s)]

(In reply to comment #39)
> And if I understand it correctly, this bug is about the inability to print to
> printers (with ppds) that other apps can print to fine, so whatever the fix is,
> this bug is where it should be made.
> If there is a theoretical bug in some ppds that won't work with ANY
> application, that's something different, but this bug is about the same ppd
> working with older builds and other applcations but NOT with current Mozilla
> trunk builds tht have the new gnomeized print dialog.
>
So that would make the new summary for this bug be:

"Mozilla should not specify a page size when printing because this is known not to work with the version of foomatic-rip provided by some Linux Disto's"?

[FredBezies (fredbezies-deactivatedaccount)]

Just some infos on my computer's software :

HPLIP : 2.8.2 =>

$ yaourt -Si hplip
Dépôt : extra
Nom : hplip
Version : 2.8.2-1

Foomatic : 18 dec 2007 version, last is 7 feb 2008.

$ yaourt -Si foomatic-filters
Dépôt : extra
Nom : foomatic-filters
Version : 3.0_20071218-1

So, mozilla bug or not ?! I will ask to archlinux coders to upgrade package version of foomatic filters.

[Kairo-kairo (kairo-kairo)]

IMHO, if we did work before the switch with those printer and settings, and others apps do as well, it's our bug for sure, and the description of the bug should be exactly that, i.e. "printing with certain printers/PPDs stopped working with the landing of bug 193001"

[Ventnor-bugzilla (ventnor-bugzilla)]

Using custom page sizes is a necessary hack to be able to integrate page size objects with the Gecko print system, because we need page sizes to be mutable at any time or else the print settings API won't work.

So we either wait for PPD maintainers to fix their bugs, or go back to our horrible old dialog. I support the former, the old dialog was too unmaintained to be of any use.

[Kairo-kairo (kairo-kairo)]

I'd vote either for the old dialog or getting an explicit page size setting in the new dialog any time when those fix it.

Needing probably thousands of people to fix their PPDs manually (I don't believe that a printer producer will any PPD they shipped when it worked fine so far and is for a printer they don't sell any more, so thaz
t's probably not an option).

[Bill-wg9s (bill-wg9s)]

(In reply to comment #44)

> Needing probably thousands of people to fix their PPDs manually (I don't

Why would anyone need to fix a PPD manually? I am printing fine by merely replacing the defective foomatic-rip perl script that shipped with fedora core 6 with the latest version (which is the same as what is currently shipping with fedora 8).

I am still using the same PPD file that I have always used.

[FredBezies (fredbezies-deactivatedaccount)]

(In reply to comment #44)
> I'd vote either for the old dialog or getting an explicit page size setting in
> the new dialog any time when those fix it.
>
> Needing probably thousands of people to fix their PPDs manually (I don't
> believe that a printer producer will any PPD they shipped when it worked fine
> so far and is for a printer they don't sell any more, so thaz
> t's probably not an option).
>

Gedit has a "paper" tab settings in its print dialog. In Minefield, you cannot modify size. Wouldn't it be simpler to modify gtk print dialog in trunk code in order to give user the possibility to change paper size and avoid modifying ppd files ?

Just guessing, of course ;)

[Ventnor-bugzilla (ventnor-bugzilla)]

(In reply to comment #46)
> (In reply to comment #44)
> > I'd vote either for the old dialog or getting an explicit page size setting in
> > the new dialog any time when those fix it.
> >
> > Needing probably thousands of people to fix their PPDs manually (I don't
> > believe that a printer producer will any PPD they shipped when it worked fine
> > so far and is for a printer they don't sell any more, so thaz
> > t's probably not an option).
> >
>
> Gedit has a "paper" tab settings in its print dialog. In Minefield, you cannot
> modify size. Wouldn't it be simpler to modify gtk print dialog in trunk code in
> order to give user the possibility to change paper size and avoid modifying ppd
> files ?
>
> Just guessing, of course ;)
>

Page Setup takes care of that.

[FredBezies (fredbezies-deactivatedaccount)]

I didn't mean that.

In "file / print" for gedit, I can get on paper tab, more options than in"file / print" minefield one.

Will attach screenshot for explaining more clearly what I wanted to say.

[FredBezies (fredbezies-deactivatedaccount)]

Created attachment 302382
gedit print dialog, "paper" tab.

Gedit file printing dialog. I can set everything I want. Page setup dialog of gedit just talks about numbers of line, fonts, and colored syntax printing.

[FredBezies (fredbezies-deactivatedaccount)]

Created attachment 302383
minefield print dialog

Paper type is set as undefined. And page setup dialog tweaking doesn't seems to change anything at all.

For me, it is a firefox bug, not a foomatic filter one because I can print with another gtk based application (like gedit) without tweaking foomatic filter.

That's all, and I think I have nothing more to add for now ;)

[Ventnor-bugzilla (ventnor-bugzilla)]

Gedit makes a custom tab in the dialog to provide those options. What is in the Minefield screenshot is the paper preferences of the standard GTK print dialog.

[FredBezies (fredbezies-deactivatedaccount)]

For the last time - before closing it as INVALID, as asked in comment #33 -
explain me why ONLY mozilla product can't print on my computer.

For me, since the landing of gtk print dialog, all is busted. I just noticed it
with HPLip 2.7.10 (and 2.8.2 show me the same bug).

Well, I am maybe too "dumb" to understand what's going on.

Can we close it so as INVALID, as asked in comment #33 ?!

My "?!" are not an attack, just a question.

[Ventnor-bugzilla (ventnor-bugzilla)]

Its because of the method we use to integrate native GTK paper objects into the Gecko print system.

Some foomatic drivers treat custom paper sizes different to standard paper sizes. Mozilla always uses custom paper sizes no matter what (even if its a standard size like A4), because you can change the properties on a custom paper object but not on a standard one. This is crucial to the Gecko Print API.

The way to fix this is to force driver maintainers to stop giving custom paper sizes special treatment.

[FredBezies (fredbezies-deactivatedaccount)]

Thanks for the explanation. So printing will be broken for a long time as I think foomatic developper won't like the way mozilla wants to see drivers to be "written".

Closing this bug as invalid is the only answer now ?!

- sigh -

[Kairo-kairo (kairo-kairo)]

In that case, I'll save my energy and locally back out bug 193001 in my tree, as I _want_ to be able to print in _my_ build. If default Gecko so badly wants to suck on Linux, there seems to be nothing I can do against it thank god I'm running my own builds so I can rip out faulty code for my own use.
It still sucks when default builds do not work on a number of (current!) Linux systems, but there seems no way around it if our own devs don't admit that we even have a bug.

[FredBezies (fredbezies-deactivatedaccount)]

I think I will try to do the same, but IT S*CKS !

I think Ubuntu 8.04 will be broken (and they're planning on introducing a "young" firefox 3 build), so will be Fedora 9, OpenSuSE 11.0, etc...

Sigh :(

[Bill-wg9s (bill-wg9s)]

(In reply to comment #56)
> I think I will try to do the same, but IT S*CKS !
>
> I think Ubuntu 8.04 will be broken (and they're planning on introducing a
> "young" firefox 3 build), so will be Fedora 9, OpenSuSE 11.0, etc...
>
> Sigh :(
>
I do not see how fedora 9 could be broken if fedora 8 includes the version of foomatic-rip which does not have the problem. Are you saying they plan to revert to the broken version?

Any distro that is shipping a version of Firefox 3 should be able to also include an up-to-date version of foomatic-filters.

This should only be an issue for old distros that are no longer supported like fedora 6.

[Kairo-kairo (kairo-kairo)]

My Canon printer problem in comment #35 is what I see on openSUSE 11.0 FACTORY (~alpha2) so it's surely broken in openSUSE 10.3, which is the current version and might even stay broken in 11.0 - but my problem could be something different, I just saw bogus-looking custom paper sizes when I tried to print the last time.

[FredBezies (fredbezies-deactivatedaccount)]

(In reply to comment #57)
[...]
>
> Any distro that is shipping a version of Firefox 3 should be able to also
> include an up-to-date version of foomatic-filters.
>

Are you sure everybody is going to upgrade distro version because of Firefox 3.0 is out ?

I really doubt on it.

Robert : What can I say ? It stinks like this bug will end as INVALID, not FIXED :(

[Bill-wg9s (bill-wg9s)]

(In reply to comment #59)
> (In reply to comment #57)
> [...]
> >
> > Any distro that is shipping a version of Firefox 3 should be able to also
> > include an up-to-date version of foomatic-filters.
> >
>
> Are you sure everybody is going to upgrade distro version because of Firefox
> 3.0 is out ?
>
Ah. I was responding specifically to your comment that Ubuntu was going to ship a Firefox 3 version.

If we could get someone to verify that installing the current version of foomatic-filters actually fixes this as requested back in comment #34 instead of posting all of these "the sky is falling" comments. We could actually try to proceed in an intelligent manner here.

If we validate that the current foomatic is a fix and relnote it, then if Linux Distributor puts out a packaged version of Firefox and does not make installation dependent on the correct version of foomatic-filters, that is really not a Mozilla issue.

That is the entire purpose of the dependency system and installing distributor supplied packages instead of doing your own.

The same applies to you comments about it being broken in future version of Linux that will ship Firefox 3. There is no reason why a future version of Linux should be shipping without a recent version of foomatic.

Once again, that is all still dependent on anyone verifying hat updating foomatic-filters is actually a fix for the issue.

Please don't try to make the problem bigger than it is. The only people who should have an issue here are those who download Firefox on their own from the Mozilla website and are running an older version of Linux with a broken version of foomatic.

I agree with you that it is not a good thing that nothing seems to be in the works to help those people out with this. This is NOT going to be viewed by end users as a Linux issue, but will be viewed as a Mozilla/Firefox issue. Even a hidden pref to prevent sending the page size would be nice.

[Kairo-kairo (kairo-kairo)]

I can't try updating foomatic-filter as I 1) don't even know if I use that package with my printer and even more 2) openSUSE doesn't offer a newer such package.

[FredBezies (fredbezies-deactivatedaccount)]

(In reply to comment #60)
[...]
> >
> > Are you sure everybody is going to upgrade distro version because of Firefox
> > 3.0 is out ?
> >
> Ah. I was responding specifically to your comment that Ubuntu was going to
> ship a Firefox 3 version.

I'm not using anymore Ubuntu, but they want to use a firefox 3.0 release for their 8.04 release.

>
> If we could get someone to verify that installing the current version of
> foomatic-filters actually fixes this as requested back in comment #34 instead
> of posting all of these "the sky is falling" comments. We could actually try to
> proceed in an intelligent manner here.

Wow ;)

>
> If we validate that the current foomatic is a fix and relnote it, then if
> Linux Distributor puts out a packaged version of Firefox and does not make
> installation dependent on the correct version of foomatic-filters, that is
> really not a Mozilla issue.

GTK Print dialog is simply busted. Printing worked before this landing.

>
> That is the entire purpose of the dependency system and installing distributor
> supplied packages instead of doing your own.
>

Am I a baby to be treated this way ? ;)

>
> The same applies to you comments about it being broken in future version of
> Linux that will ship Firefox 3. There is no reason why a future version of
> Linux should be shipping without a recent version of foomatic.

I tested Zenwalk 5.0 (released a week ago) in a virtual machine.

Foomatic filters from 18 december (the previous stable version) and printing task started flawlessly. So foomatic seems to be not guilty here.

>
> Once again, that is all still dependent on anyone verifying hat updating
> foomatic-filters is actually a fix for the issue.

Well, foomatic filters on Zenwalk 5.0 are not the latest one and printing works.

>
> Please don't try to make the problem bigger than it is. The only people who
> should have an issue here are those who download Firefox on their own from the
> Mozilla website and are running an older version of Linux with a broken
> version of foomatic.
>

Well, something strange. So why the foomatic version given with zenwalk 5.0 is plainly working ?!

> I agree with you that it is not a good thing that nothing seems to be in the
> works to help those people out with this. This is NOT going to be viewed by
> end users as a Linux issue, but will be viewed as a Mozilla/Firefox issue.
> Even a hidden pref to prevent sending the page size would be nice.
>

Or just back out gtk printing dialog and finding why it is not really working.

Robert : +1

[Bill-wg9s (bill-wg9s)]

(In reply to comment #61)
> I can't try updating foomatic-filter as I 1) don't even know if I use that
> package with my printer and even more 2) openSUSE doesn't offer a newer such
> package.
>
I highly suspect that if you seeing this issue you are printing via the foomatic-rip filter.

The fact that your distributer does not offer a newer version of foomatic than what you are running should not prevent you from testing this. Just download and install foomatic-filters form the link I provided in comment #33. It is not necessary to download the other components. This will alter /usr/lib/cups/filter/foomatic-rip to be symbolic link to /usr/local/bin/foomatic-rip (you should note what this currently is (probably a symlink to /usr/bin/foomatic-rip) in case you want to back this out.

That is what I did as there no longer seem to be updated packages for anything under fedora 6.

This should just work as foomatic-rip is just a non-architecture non distribution specific perl script.

If this fixes the issue for you it is a good thing to do irrelevant of Mozilla ans this is really a latent Linux printing issue just waiting to rear it's ugly head if any application specifies a page size for any reason.

[Bill-wg9s (bill-wg9s)]

(In reply to comment #60)
> I agree with you that it is not a good thing that nothing seems to be in the
> works to help those people out with this. This is NOT going to be viewed by
> end users as a Linux issue, but will be viewed as a Mozilla/Firefox issue.
> Even a hidden pref to prevent sending the page size would be nice.
>
The more I think about it, the more I like the hidden preference idea. There are going to be users on a multi-user Linux system who do not have any admin rights to install new printer filters etc, who might install Firefox for their own use. They would have no way to get printing to work.

If there were a hidden preference, I could write an extension to set the preference for people who either can't or do not want to fix the underlying Linux issue for whatever reason.

[FredBezies (fredbezies-deactivatedaccount)]

Some more infos ;)

If I tweak my ppd file (cf comment #26), I can print. But in a 32bits virtual machine running ZenWalk 5.0 and "old" (I mean december 2007) version of my ppd file, printing run.

But not on a 64 bits OS like my ArchLinux, which share THE SAME version of foomatic filters.

I'm kinda lost ! :(

So, it could be a 64 bits linux issue because ZenWalk 5.0 - 32 bits distro works.

If somebody running a 32 bits distro can't confirm this bug, we will have more idea of what's going on.

[Kairo-kairo (kairo-kairo)]

sorry to bust your theory, but my case is on a 32bit system.

[Kairo-kairo (kairo-kairo)]

And I have the foomatic-filters-3.0.2-173 package from openSUSE FACTORY, no idea what version the foomatic-rip script is.

[Kairo-kairo (kairo-kairo)]

all that said, I might not be using foomatic-filter but bjfilter-pixusip4100 as released a long time ago by Canon Japan (even under the GPL), but this package doesn't get updated any more as Canon probably doesn't sell those printer any more and therefore doesn't develop any code they have written further (apart from those packages not being available from Canon international but only after jumping through some loops at Canon Japan, where that code was developed).

[Roc-ocallahan (roc-ocallahan)]

As far as I can tell, this is a case where we starting using a GTK feature (custom paper sizes) and it just doesn't work on some systems, probably because of print driver bugs. Strictly speaking that is not our problem, but we should work around it if we can.

Michael, in this case could we work around it by, just before we print, replacing the GTK custom paper size object with a default paper size object when the custom paper is the same size as the default paper with the same name?

[Ventnor-bugzilla (ventnor-bugzilla)]

Created attachment 302475
Workaround?

Roc, can you give this to Karl to see if this works? This implements your workaround suggestion.

[Roc-ocallahan (roc-ocallahan)]

Karl's kinda busy and it's a pain to mess with the printer, maybe someone else can test the patch? But it looks good to me. One thing that would be nice, instead of the mPaperSizeWorkaround variable, just always copy mGtkPageSetup and mGTKPrintSettings so we can unref them unconditionally in EndDocument or better still the nsDeviceContextSpecGTK destructor. Similarly we could always make a copy of the paper size so we can always free it in the destructor.

[Ventnor-bugzilla (ventnor-bugzilla)]

(In reply to comment #71)
> Karl's kinda busy and it's a pain to mess with the printer, maybe someone else
> can test the patch? But it looks good to me. One thing that would be nice,
> instead of the mPaperSizeWorkaround variable, just always copy mGtkPageSetup
> and mGTKPrintSettings so we can unref them unconditionally in EndDocument or
> better still the nsDeviceContextSpecGTK destructor. Similarly we could always
> make a copy of the paper size so we can always free it in the destructor.
>

It needs to be conditional because if the paper size object was changed with the Gecko Print API we do NOT want to copy the standard object, which we would otherwise since the names are kept the same.

[Roc-ocallahan (roc-ocallahan)]

It can still be conditional, it's just that if the custom size is not the standard size, you make a copy of the custom size instead. If paper sizes were refcounted we'd just addref the custom size object, but of course they aren't.

[Bill-wg9s (bill-wg9s)]

(In reply to comment #70)
> Created an attachment (id=302475) [details]
> Workaround?
>
> Roc, can you give this to Karl to see if this works? This implements your
> workaround suggestion.
>
Something is not quite right with this patch. With this patch, it does correctly send the file to the printer specifying the PageSize as Letter, but the Firefox UI freezes immediately thereafter.

[Bill-wg9s (bill-wg9s)]

(In reply to comment #74)
> (In reply to comment #70)
> > Created an attachment (id=302475) [details] [details]
> > Workaround?
> >
> > Roc, can you give this to Karl to see if this works? This implements your
> > workaround suggestion.
> >
> Something is not quite right with this patch. With this patch, it does
> correctly send the file to the printer specifying the PageSize as Letter, but
> the Firefox UI freezes immediately thereafter.
>

Removing either of these 2 lines appears to avoid the hang:

+ gtk_paper_size_free(gtk_page_setup_get_paper_size(mGtkPageSetup));
+ g_object_unref(mGtkPageSetup);

Although that probably results in leaks.

[Roc-ocallahan (roc-ocallahan)]

Ah, what if you move the gtk_paper_size_free call to after g_object_unref(mGtkPageSetup)? We probably should free it *after* we've stopped using it in mGtkPageSetup...

[Bill-wg9s (bill-wg9s)]

(In reply to comment #76)
> Ah, what if you move the gtk_paper_size_free call to after
> g_object_unref(mGtkPageSetup)? We probably should free it *after* we've stopped
> using it in mGtkPageSetup...
>

That did not help. What I am using now is this:

      gtk_paper_size_free(gtk_page_setup_get_paper_size(mGtkPageSetup));
      // g_object_unref(mGtkPageSetup);
      g_object_unref(mGtkPrintSettings);

I have tired shuffling the order of these around several other different ways but always come down to I can't do both the gtk_paper_size_free and the g_object_unref(mGtkPageSetup) without encountering the hang issue.

[Bill-wg9s (bill-wg9s)]

I have posted a Firefox build including a non-hanging version of this patch on my server at:

http://www.wg9s.com/mozilla/firefox/

It would help if people could verify that this fixes their printing issues.

[c7d2f5c8667d26fffd5e7772d632c76d (c7d2f5c8667d26fffd5e7772d632c76d-deactivatedaccount)]

+ gtk_paper_size_free(gtk_page_setup_get_paper_size(mGtkPageSetup));
+ g_object_unref(mGtkPageSetup);

The paper size object is owned by mGtkPageSetup; you're not allowed to free it. Just unref the page setup.

[Bill-wg9s (bill-wg9s)]

There is a new testing build available with an updated patch based on the information in comment #79:

http://www.wg9s.com/mozilla/firefox/

[Kairo-kairo (kairo-kairo)]

yay, I patched my builds with the workaround and I can print again! Thanks for figuring that out, Michael!

[FredBezies (fredbezies-deactivatedaccount)]

I confirm last comment. I hope patch could be added without generating any regressions.

[Ventnor-bugzilla (ventnor-bugzilla)]

Created attachment 302679
Workaround

[Roc-ocallahan (roc-ocallahan)]

Comment on attachment 302679
Workaround

great

[Bill-wg9s (bill-wg9s)]

Too bad this is way to late to make beta3 :-(

[Blizzard (blizzard)]

Robert, when you check that in can you just put this bug number in the comment before the hacky code?

[Reed Loden (reed)]

Checking in widget/src/gtk2/nsDeviceContextSpecG.cpp;
/cvsroot/mozilla/widget/src/gtk2/nsDeviceContextSpecG.cpp,v <-- nsDeviceContextSpecG.cpp
new revision: 1.101; previous revision: 1.100
done

[Dave Morley (davmor2)]

Binary package hint: firefox-3.0

Printing has stopped functioning in FF3 beta 3. If you hit the print option in FireFox it seem to send the file to the print queue but then in the print queue it say print stopped and doesn't print anything.

This is the Cups error log

E [22/Feb/2008:21:01:17 +0100] [Job 25] pdftops-options: -cfg /etc/cups/pdftops.conf
E [22/Feb/2008:21:01:17 +0100] [Job 25] /usr/bin/pdftops exited with exit code 1
E [22/Feb/2008:21:01:17 +0100] PID 1247 (/usr/lib/cups/filter/pdftops) stopped with status 1!
E [22/Feb/2008:21:01:17 +0100] [Job 25] Empty print file!
E [22/Feb/2008:21:01:17 +0100] PID 1249 (/usr/lib/cups/filter/pstops) stopped with status 1!
E [22/Feb/2008:21:01:18 +0100] PID 1251 (/usr/lib/cups/filter/rastertospl2) stopped with status 1!
E [22/Feb/2008:21:01:19 +0100] PID 1252 (/usr/lib/cups/backend/ipp) stopped with status 1!

[Jacob Peddicord (jpeddicord)]

Thanks for the report. Confirmed, and as far as I know this is fixed in the upcoming Beta 4.

[miked (miked11)]

Ubuntu Hardy Heron 8.04 Alpha4
Trying to Print WebPage on networked printer; closes browser, and cycles printer paper.

[miked (miked11)]

Ubuntu Hardy Heron 8.04 Alpha4
root@tower-desktop:~#
different computer, printer local
SwiftWeasel WebBrowser 2.0.0.8 & 2.0.0.12 does not print either, sends job it to the printer queue and then stops it from printing, restarting it, it quickly stops again.

[miked (miked11)]

Ubuntu Hardy Heron 8.04 Alpha4
root@tower-desktop:~#
printer local
Firefox3Pre
Click File->Print
Pop-up window appears
Under status section it reads: /usr/lib/cups/rastertospl2 failed.

[miked (miked11)]

Sorry, meant to add this to last comment.
Clicking Print button, causes Print window to close, processing pop-up window appears % counts up.
Browser closes. no print out.
I know this is confirmed, but I think this affects more than just Firefox 3 Pre, I would suggest adding a package like cups, or whatever related to printing to this bug report, waiting till Firefox 3 Preview Beta 4, sounds like it could take awhile, I don't know when it comes out, and will that fix the cups/rastertospl2 failing thing?

[miked (miked11)]

https://bugs.launchpad.net/ubuntu/+source/cupsys/+bug/194302

[Alexander Sack (asac)]

fix will be released with beta4

[Brock Williams (brock-cotcomsol)]

I had the same problem and fixed it easily by installing package xpdf-utils
Seems the pdftops wasn't working due to that package being missing.

[Joe Smetona (joe-smetona)]

Thanks very much, I appreciate your help.

It's working very well otherwise - we're using it as a family computer, so
it's doing very well considering 5 people are on it at various times.

I'll give it a try.

Joe Smetona

On Tue, Feb 26, 2008 at 2:53 PM, Brock Williams <email address hidden> wrote:

> I had the same problem and fixed it easily by installing package
> xpdf-utils
> Seems the pdftops wasn't working due to that package being missing.
>
> --
> printing in Firefox 3 Beta 3 is broken
> https://bugs.launchpad.net/bugs/194486
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

--
Joe Smetona Jr.
402 Third Avenue
Haddon Heights, NJ 08035
------ USA ----------------------
[phone] home
[phone] cell

[Martin Emrich (emme)]

As an ugly workaround until the fix is released: Save the page ("Web page, complete") and print it via epiphany-browser.

Ciao

Martin

[Joe Smetona (joe-smetona)]

I just installed the Epiphany browser and it plotted Web material OK. (My
family is using the setup for everyday work.) That's the only problem I
have found. Thanks very much for the info

Joe Smetona
<email address hidden>.

On Wed, Feb 27, 2008 at 2:19 AM, Martin Emrich <email address hidden> wrote:

> As an ugly workaround until the fix is released: Save the page ("Web
> page, complete") and print it via epiphany-browser.
>
> Ciao
>
> Martin
>
> --
> printing in Firefox 3 Beta 3 is broken
> https://bugs.launchpad.net/bugs/194486
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

--
Joe Smetona Jr.
402 Third Avenue
Haddon Heights, NJ 08035
------ USA ----------------------
[phone] home
[phone] cell

[mabovo (mabovo)]

Firefox 3 in Hardy 8.04 Alpha 5 still not printing. Message: " Printer maybe disconnected"
Printing from text editor or openoffice.org writer doesn't have any problem.

[Dave Morley (davmor2)]

Fixed :)

[Michael Losonsky (michl)]

Strange, I don't have any problems printing in Beta 3. Using
Hardy.

[Ryan Sinn (ryan-sinn)]

I didn't have any problems printing in Beta 3, but now Printing is Broken in Beta 4

[Ryan Sinn (ryan-sinn)]

I've tried printing to a network HP JetDirect printer (IP-based) and directly to the "PDF" printer... both crash on "preparing".

I installed with Alpha4 a month ago... and have been updating daily.
I'm currently up to date with updates as of today, 2008-03-17...

[Alexander Sack (asac)]

xulrunner-1.9 (1.9~b4+nobinonly-0ubuntu1) hardy; urgency=low

  * new upstream release 1.9~b4 fixes:
    - LP: #194486 - "printing in Firefox 3 Beta 3 is broken"
    - LP: #192505 - "Where's my home button?"
    - LP: #44062 - "Firefox allows cookies to be set for second-level
      domain hierarchies"
    - LP: #181575 - "pressing Enter in URL bar selects mouse hover target
      in substring-search pop-down"

  [ Fabien Tassin <email address hidden> ]
  * Drop patches applied upstream
    - drop debian/patches/bz344818_cairo_xrender.patch
    - drop debian/patches/bzXXX_fix_pyxpcom_build_failure.patch
  * Update diverged patch:
    - update debian/patches/dom_inspector_support_for_prism.patch
  * Add support for system hunspell
    - update debian/rules
  * Add optional support for system sqlite3 (we need >= 3.5 not in hardy)
    - update debian/rules
  * Update clean rule to make it simpler and more friendly with
    mozilla-devscripts
    - update debian/rules
  * Drop DEB_AUTO_UPDATE_DEBIAN_CONTROL cdbs variable completely. It was
    wrongly set to zero
    - update debian/rules
  * Update clean rule now that Mozilla bug 333308 has landed.
    To prevent a bug in cdbs where patches are unapplied before distclean
    is performed, set DEB_MAKE_CLEAN_TARGET to $(NULL) and add call
    distclean ourselves before cdbs files are included
    - update debian/rules
  * There're still some leftovers after distclean despite latest
    Mozilla bug 333308 patch. Fix it once again and report it upstream
    - add debian/patches/bz333308_attXXXX_make_clean_cleaner.patch
    - update debian/patches/series
  * Drop obsolete comment for extensions
    - update debian/rules
  * Stop build-tree/mozilla/README to be shipped as a doc by setting
    cdbs DEB_INSTALL_DOCS_ALL to $(NULL)
    - update debian/rules
  * Drop obsolete TODO file
    - drop debian/TODO

  [ Alexander Sack < <email address hidden>> ]
  * fix "remember password" dialog for embedders that don't provide
    a branding chrome
    - add debian/patches/bzXXX_attXXX_fix_remember_password_for_embedders_without_branding.patch
    - update debian/patches/series
  * fix LP: #175904 "Firefox 3.0 makes everything annoyingly huge" by not
    scaling images based on dpi.
    - add debian/patches/bz394103_dont_scale_images.patch
    - update debian/patches/series
  * add alternative patch for LP: #175904 "Firefox 3.0 makes everything
    annoyingly huge" by scaling images for 192dpi, 288dpi, etc. instead
    of 142dpi, 238dpi and so on. (this patch is not applied atm and is
    included for testing purpose)
    - add debian/patches/bz394103_scale_images_for_192+dpi.patch
  * add libsqlite3-dev to Build-Depends in order to effectively enable
    optional system sqlite feature on buildd's with sqlite > 3.5
    - update debian/control
  * bump build requirements on nspr and nss to >= 4.7.0~1.9b4 and
    >= 3.12.0~1.9b4 respectively
    - update debian/control

 -- Alexander Sack < <email address hidden>> Tue, 11 Mar 2008 02:06:46 +0100

[david wood (david-wood)]

I am not sure I am reading this right, but this seems to indicate the problem is fixed? However I am current on 8.04 as of today and am still unable to print in FF3b5, yet am able to print in everything else (konqueror, etc).

Possibly relevant line from /var/log/cups/errors_log:

E [30/May/2008:18:52:55 -0400] cupsdReadClient: 7 IPP Read Error!

[Adam Gundy (adam-starsilk)]

still fails for me with an up to date hardy. printing from FF3 fails. printing the exact same page from FF2 works.

this is with a Samsung ML-2010 laser, connected with a Netgear PS-121 network adapter. well worth pointing out for a second time that provided I avoid FF3, this setup works perfectly.

so, in an attempt to rule out the PS-121, I set up another machine (Dapper) to share the printer via cups, and changed my Hardy machine to point to it over IPP.

FF3 still fails to print. I found this in /var/log/cups/errors_log:

E [14/Jun/2008:21:02:11 -0600] [Job 1] No %%BoundingBox: comment in header!

[Adam Gundy (adam-starsilk)]

after reading some of the related bugs to this one, I guess I should add that this was a clean Hardy install, not an upgrade.

[Alexander Sack (asac)]

On Sun, Jun 15, 2008 at 03:30:55AM -0000, Adam Gundy wrote:
> still fails for me with an up to date hardy. printing from FF3 fails.
> printing the exact same page from FF2 works.
>
> this is with a Samsung ML-2010 laser, connected with a Netgear PS-121
> network adapter. well worth pointing out for a second time that provided
> I avoid FF3, this setup works perfectly.
>
> so, in an attempt to rule out the PS-121, I set up another machine
> (Dapper) to share the printer via cups, and changed my Hardy machine to
> point to it over IPP.
>
> FF3 still fails to print. I found this in /var/log/cups/errors_log:
>
> E [14/Jun/2008:21:02:11 -0600] [Job 1] No %%BoundingBox: comment in
> header!
>

This one is close and since we are not sure that your issue is the
same that this bug was about, please open a new bug. Consider to drp
the new bug id here for reference.

 - Alexander