Since landing of bug 193001, I cannot print with HP-Toolbox 2.7.10 or earlier

RESOLVED FIXED in mozilla1.9beta4

Status

()

Core
Widget: Gtk
--
major
RESOLVED FIXED
10 years ago
7 years ago

People

(Reporter: Frederic Bezies, Assigned: Michael Ventnor)

Tracking

Trunk
mozilla1.9beta4
x86
Linux
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(7 attachments, 1 obsolete attachment)

(Reporter)

Description

10 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9b3pre) Gecko/2008012716 Firefox/3.0b3pre
Build Identifier: 

I can see it either in trunk versions of Firefox or Thunderbird.

Since landing of but 193001, tasks are sent to HP-toolbox (for my HP printer), and nothing goes out. Task is listed as stopped.

I installed a firefox 2.0.0.11, and printing works flawlessly :(

Reproducible: Always

Steps to Reproduce:
1.Get a trunk build since bug 193001 as landed
2.Go to google.com
3.Try to print...
Actual Results:  
Nothing. Task is listed as stopped :(

Expected Results:  
Printing going on !

Using ArchLinux, HP-LIP 2.7.10, and a 15 hours old homemade trunk build.
(Reporter)

Comment 1

10 years ago
It is a major bug for linux user with HP printers... And there are a lot of them ;)
Flags: blocking1.9?
(Reporter)

Updated

10 years ago
Depends on: 193001
Assignee: nobody → ventnor.bugzilla
Blocks: 193001
Component: Printing → Widget: Gtk
No longer depends on: 193001
QA Contact: printing → gtk
Version: unspecified → Trunk
(Assignee)

Comment 2

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

Comment 3

10 years ago
Which version of HP-Lip do you have ? Which HP ?

I have HPLip 2.7.10 and a PSC3180 printer (all-in-one) hardware.
Can you print using other GTK apps that use the GTK print dialog?
(Reporter)

Comment 5

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

And no errors in error console :(

This makes me really sad !
(Reporter)

Comment 6

10 years ago
Created attachment 299765 [details]
screenshot of error.

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

Comment 7

10 years ago
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.
Summary: SInce landing of bug 193001, I cannot get a print to be done with HP-Toolbox. → SInce landing of bug 193001, I cannot get a print to be done with HP-Toolbox 2.7.10
If you print to PDF and then print that PDF, does that work?
(Reporter)

Comment 9

10 years ago
yes. But it is not a great way to get a page printed.
(Reporter)

Comment 10

10 years ago
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 ?
(Reporter)

Comment 11

10 years ago
Created attachment 300393 [details]
screenshot of cups webui showing the "unknown number of pages".

Could it explain the stopped task in hlplip ?!
(Reporter)

Comment 12

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

Comment 13

10 years ago
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...
(Reporter)

Comment 14

10 years ago
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
(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.
(Reporter)

Comment 16

10 years ago
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 !
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → INVALID

Comment 17

10 years ago
(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)
(Reporter)

Comment 18

10 years ago
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 :(
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Karl uses 64-bit builds, he may be able to reproduce the problem.
(Reporter)

Comment 20

10 years ago
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 :)
Created attachment 300759 [details]
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.
print_job: auto-typing file...
print_job: request file type is application/pdf.

Do we submit a pdf?
Created attachment 300761 [details]
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.

Updated

10 years ago
Attachment #300761 - Attachment mime type: text/x-log → text/plain
(Assignee)

Comment 24

10 years ago
(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.
(Reporter)

Comment 25

10 years ago
Why a pdf ? Is this the key of the problem ?!

Very strange :(

Ah, 64 bits OS pleasure ;)
Flags: blocking1.9? → blocking1.9+
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: ""
(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.

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.
(Reporter)

Comment 29

10 years ago
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 :(
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).
Unfortunately, the landing of the code for bug 406376 and bug 415425 has not fixed this issue.
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--
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
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?

Comment 35

10 years ago
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.
(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.
(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.

Comment 38

10 years ago
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.

Comment 39

10 years ago
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.
(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"?
(Reporter)

Comment 41

10 years ago
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.

Comment 42

10 years ago
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"
(Assignee)

Comment 43

10 years ago
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.

Comment 44

10 years ago
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).
(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.
(Reporter)

Comment 46

10 years ago
(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 ;)
(Assignee)

Comment 47

10 years ago
(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.
(Reporter)

Comment 48

10 years ago
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.
(Reporter)

Comment 49

10 years ago
Created attachment 302382 [details]
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.
Summary: SInce landing of bug 193001, I cannot get a print to be done with HP-Toolbox 2.7.10 → Since landing of bug 193001, I cannot print with HP-Toolbox 2.7.10
(Reporter)

Comment 50

10 years ago
Created attachment 302383 [details]
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 ;)
(Assignee)

Comment 51

10 years ago
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.
(Reporter)

Updated

10 years ago
Summary: Since landing of bug 193001, I cannot print with HP-Toolbox 2.7.10 → Since landing of bug 193001, I cannot print with HP-Toolbox 2.7.10 or younger
Summary: Since landing of bug 193001, I cannot print with HP-Toolbox 2.7.10 or younger → Since landing of bug 193001, I cannot print with HP-Toolbox 2.7.10 or earlier
(Reporter)

Comment 52

10 years ago
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.
(Assignee)

Comment 53

10 years ago
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.
(Reporter)

Comment 54

10 years ago
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 - 

Comment 55

10 years ago
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.
(Reporter)

Comment 56

10 years ago
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 :(
(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.

Comment 58

10 years ago
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.
(Reporter)

Comment 59

10 years ago
(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 :(
(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.


Comment 61

10 years ago
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.
(Reporter)

Comment 62

10 years ago
(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

(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.
(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.
(Reporter)

Comment 65

10 years ago
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.

Comment 66

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

Comment 67

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

Comment 68

10 years ago
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).
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?
(Assignee)

Comment 70

10 years ago
Created attachment 302475 [details] [diff] [review]
Workaround?

Roc, can you give this to Karl to see if this works? This implements your workaround suggestion.
Attachment #302475 - Flags: superreview?(roc)
Attachment #302475 - Flags: review?(roc)
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.
(Assignee)

Comment 72

10 years ago
(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.
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.
(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.
(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.
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...
(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.
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.
+      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.
There is a new testing build available with an updated patch based on the information in comment #79:

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

Comment 81

10 years ago
yay, I patched my builds with the workaround and I can print again! Thanks for figuring that out, Michael!
(Reporter)

Comment 82

10 years ago
I confirm last comment. I hope patch could be added without generating any regressions.
Keywords: relnote
(Assignee)

Comment 83

10 years ago
Created attachment 302679 [details] [diff] [review]
Workaround
Attachment #302475 - Attachment is obsolete: true
Attachment #302679 - Flags: superreview?(roc)
Attachment #302679 - Flags: review?(roc)
Attachment #302475 - Flags: superreview?(roc)
Attachment #302475 - Flags: review?(roc)
Comment on attachment 302679 [details] [diff] [review]
Workaround

great
Attachment #302679 - Flags: superreview?(roc)
Attachment #302679 - Flags: superreview+
Attachment #302679 - Flags: review?(roc)
Attachment #302679 - Flags: review+
Too bad this is way to late to make beta3 :-(
(Assignee)

Updated

10 years ago
Keywords: checkin-needed
Robert, when you check that in can you just put this bug number in the comment before the hacky code?
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
Status: REOPENED → RESOLVED
Last Resolved: 10 years ago10 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9beta4
Depends on: 417351
Keywords: relnote

Updated

7 years ago
Depends on: 626539
You need to log in before you can comment on or make changes to this bug.