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.

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

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

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?

Of course, I can. For example with gedit, or epiphany web browser. And no errors in error console :( This makes me really sad !

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

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.

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

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

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 ?

Could it explain the stopped task in hlplip ?!

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

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...

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.

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 !

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

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 :(

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

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 :)

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?

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.

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

Why a pdf ? Is this the key of the problem ?! Very strange :( Ah, 64 bits OS pleasure ;)

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.

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?

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.

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.

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"?

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.

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"

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.

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.

(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 ;)

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

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.

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.

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 ;)

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.

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.

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.

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 -

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.

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.

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.

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

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.

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

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.

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

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

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?

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

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.

(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/

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

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

Comment on attachment 302679 [details] [diff] [review] Workaround great

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

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