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

[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