printing in Firefox 3 Beta 3 is broken
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Mozilla Firefox |
Fix Released
|
High
|
|||
firefox-3.0 (Ubuntu) |
Fix Released
|
High
|
Unassigned |
Bug Description
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/
E [22/Feb/
E [22/Feb/
E [22/Feb/
E [22/Feb/
E [22/Feb/
E [22/Feb/
Related branches
In Mozilla Bugzilla #414314, FredBezies (fredbezies-deactivatedaccount) wrote : | #1 |
In Mozilla Bugzilla #414314, Ventnor-bugzilla (ventnor-bugzilla) wrote : | #2 |
Weird, we have a HP printer in the NZ office and it seems to work perfectly. Can anyone else reproduce this?
In Mozilla Bugzilla #414314, FredBezies (fredbezies-deactivatedaccount) wrote : | #3 |
Which version of HP-Lip do you have ? Which HP ?
I have HPLip 2.7.10 and a PSC3180 printer (all-in-one) hardware.
In Mozilla Bugzilla #414314, Roc-ocallahan (roc-ocallahan) wrote : | #4 |
Can you print using other GTK apps that use the GTK print dialog?
In Mozilla Bugzilla #414314, FredBezies (fredbezies-deactivatedaccount) wrote : | #5 |
Of course, I can. For example with gedit, or epiphany web browser.
And no errors in error console :(
This makes me really sad !
In Mozilla Bugzilla #414314, FredBezies (fredbezies-deactivatedaccount) wrote : | #6 |
Created attachment 299765
screenshot of error.
Here is what I got while trying to print using firefox trunk version.
In Mozilla Bugzilla #414314, FredBezies (fredbezies-deactivatedaccount) wrote : | #7 |
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://
Editing title.
In Mozilla Bugzilla #414314, Roc-ocallahan (roc-ocallahan) wrote : | #8 |
If you print to PDF and then print that PDF, does that work?
In Mozilla Bugzilla #414314, FredBezies (fredbezies-deactivatedaccount) wrote : | #9 |
yes. But it is not a great way to get a page printed.
In Mozilla Bugzilla #414314, FredBezies (fredbezies-deactivatedaccount) wrote : | #10 |
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 ?
In Mozilla Bugzilla #414314, FredBezies (fredbezies-deactivatedaccount) wrote : | #11 |
Created attachment 300393
screenshot of cups webui showing the "unknown number of pages".
Could it explain the stopped task in hlplip ?!
In Mozilla Bugzilla #414314, FredBezies (fredbezies-deactivatedaccount) wrote : | #12 |
I wonder also if it is a 64 bits bug only. It could be a really bad thing :(
In Mozilla Bugzilla #414314, Ventnor-bugzilla (ventnor-bugzilla) wrote : | #13 |
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...
In Mozilla Bugzilla #414314, FredBezies (fredbezies-deactivatedaccount) wrote : | #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 ?!
I'm completely lost here.
Here is my .mozconfig, if it could help :
#
# See http://
#
. $topsrcdir/
# Options for 'configure' (same as command-line options).
ac_add_options --enable-
ac_add_options --disable-debug
ac_add_options --disable-tests
ac_add_options --enable-
ac_add_options --enable-strip
ac_add_options --disable-mochitest
In Mozilla Bugzilla #414314, Jwalden+bmo (jwalden+bmo) wrote : | #15 |
(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.
In Mozilla Bugzilla #414314, FredBezies (fredbezies-deactivatedaccount) wrote : | #16 |
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 Mozilla Bugzilla #414314, Bugzilla-tuxmachine (bugzilla-tuxmachine) wrote : | #17 |
(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+
In Mozilla Bugzilla #414314, FredBezies (fredbezies-deactivatedaccount) wrote : | #18 |
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 :(
In Mozilla Bugzilla #414314, Roc-ocallahan (roc-ocallahan) wrote : | #19 |
Karl uses 64-bit builds, he may be able to reproduce the problem.
In Mozilla Bugzilla #414314, FredBezies (fredbezies-deactivatedaccount) wrote : | #20 |
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 :)
In Mozilla Bugzilla #414314, Karlt (karlt) wrote : | #21 |
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.
In Mozilla Bugzilla #414314, Karlt (karlt) wrote : | #22 |
print_job: auto-typing file...
print_job: request file type is application/pdf.
Do we submit a pdf?
In Mozilla Bugzilla #414314, Karlt (karlt) wrote : | #23 |
Created attachment 300761
foomatic-rip.log
failure in ghostscript:
Unrecoverable error: configurationerror in setpagedevice
Operand stack:
true --nostringval--
/tmp/foomatic-
In Mozilla Bugzilla #414314, Ventnor-bugzilla (ventnor-bugzilla) wrote : | #24 |
(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.
In Mozilla Bugzilla #414314, FredBezies (fredbezies-deactivatedaccount) wrote : | #25 |
Why a pdf ? Is this the key of the problem ?!
Very strange :(
Ah, 64 bits OS pleasure ;)
In Mozilla Bugzilla #414314, Karlt (karlt) wrote : | #26 |
Printing works for me if I change the following lines in the printer ppd file from
*FoomaticRIPOpt
EVICEHEIGHTPOIN
to
*FoomaticRIPOpt
In Mozilla Bugzilla #414314, Bill-wg9s (bill-wg9s) wrote : | #27 |
(In reply to comment #26)
> Printing works for me if I change the following lines in the printer ppd file
> from
>
> *FoomaticRIPOpt
> EVICEHEIGHTPOIN
>
> to
>
> *FoomaticRIPOpt
>
This "fixed" the issue for me as well.
In Mozilla Bugzilla #414314, Bill-wg9s (bill-wg9s) wrote : | #28 |
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.
In Mozilla Bugzilla #414314, FredBezies (fredbezies-deactivatedaccount) wrote : | #29 |
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 :(
In Mozilla Bugzilla #414314, Bill-wg9s (bill-wg9s) wrote : | #30 |
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).
In Mozilla Bugzilla #414314, Bill-wg9s (bill-wg9s) wrote : | #31 |
Unfortunately, the landing of the code for bug 406376 and bug 415425 has not fixed this issue.
In Mozilla Bugzilla #414314, Karlt (karlt) wrote : | #32 |
I get the same error with lpr and Custom media sizes.
lpr -P HP_Officejet_
foomatic-
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-
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--
In Mozilla Bugzilla #414314, Bill-wg9s (bill-wg9s) wrote : | #33 |
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://
In Mozilla Bugzilla #414314, Jwalden+bmo (jwalden+bmo) wrote : | #34 |
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?
In Mozilla Bugzilla #414314, Kairo-kairo (kairo-kairo) wrote : | #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.
In Mozilla Bugzilla #414314, Bill-wg9s (bill-wg9s) wrote : | #36 |
(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 Mozilla Bugzilla #414314, Bill-wg9s (bill-wg9s) wrote : | #37 |
(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.
In Mozilla Bugzilla #414314, Kairo-kairo (kairo-kairo) wrote : | #38 |
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.
In Mozilla Bugzilla #414314, Kairo-kairo (kairo-kairo) wrote : | #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.
In Mozilla Bugzilla #414314, Bill-wg9s (bill-wg9s) wrote : | #40 |
(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"?
29 comments hidden Loading more comments | view all 109 comments |
In Mozilla Bugzilla #414314, Ventnor-bugzilla (ventnor-bugzilla) wrote : | #70 |
Created attachment 302475
Workaround?
Roc, can you give this to Karl to see if this works? This implements your workaround suggestion.
In Mozilla Bugzilla #414314, Roc-ocallahan (roc-ocallahan) wrote : | #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 mPaperSizeWorka
In Mozilla Bugzilla #414314, Ventnor-bugzilla (ventnor-bugzilla) wrote : | #72 |
(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 mPaperSizeWorka
> and mGTKPrintSettings so we can unref them unconditionally in EndDocument or
> better still the nsDeviceContext
> 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.
In Mozilla Bugzilla #414314, Roc-ocallahan (roc-ocallahan) wrote : | #73 |
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 Mozilla Bugzilla #414314, Bill-wg9s (bill-wg9s) wrote : | #74 |
(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 Mozilla Bugzilla #414314, Bill-wg9s (bill-wg9s) wrote : | #75 |
(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_
+ g_object_
Although that probably results in leaks.
In Mozilla Bugzilla #414314, Roc-ocallahan (roc-ocallahan) wrote : | #76 |
Ah, what if you move the gtk_paper_size_free call to after g_object_
In Mozilla Bugzilla #414314, Bill-wg9s (bill-wg9s) wrote : | #77 |
(In reply to comment #76)
> Ah, what if you move the gtk_paper_size_free call to after
> g_object_
> using it in mGtkPageSetup...
>
That did not help. What I am using now is this:
gtk_
// g_object_
g_
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_
In Mozilla Bugzilla #414314, Bill-wg9s (bill-wg9s) wrote : | #78 |
I have posted a Firefox build including a non-hanging version of this patch on my server at:
http://
It would help if people could verify that this fixes their printing issues.
In Mozilla Bugzilla #414314, c7d2f5c8667d26fffd5e7772d632c76d (c7d2f5c8667d26fffd5e7772d632c76d-deactivatedaccount) wrote : | #79 |
+ gtk_paper_
+ g_object_
The paper size object is owned by mGtkPageSetup; you're not allowed to free it. Just unref the page setup.
In Mozilla Bugzilla #414314, Bill-wg9s (bill-wg9s) wrote : | #80 |
There is a new testing build available with an updated patch based on the information in comment #79:
In Mozilla Bugzilla #414314, Kairo-kairo (kairo-kairo) wrote : | #81 |
yay, I patched my builds with the workaround and I can print again! Thanks for figuring that out, Michael!
In Mozilla Bugzilla #414314, FredBezies (fredbezies-deactivatedaccount) wrote : | #82 |
I confirm last comment. I hope patch could be added without generating any regressions.
In Mozilla Bugzilla #414314, Ventnor-bugzilla (ventnor-bugzilla) wrote : | #83 |
Created attachment 302679
Workaround
In Mozilla Bugzilla #414314, Roc-ocallahan (roc-ocallahan) wrote : | #84 |
Comment on attachment 302679
Workaround
great
In Mozilla Bugzilla #414314, Bill-wg9s (bill-wg9s) wrote : | #85 |
Too bad this is way to late to make beta3 :-(
In Mozilla Bugzilla #414314, Blizzard (blizzard) wrote : | #86 |
Robert, when you check that in can you just put this bug number in the comment before the hacky code?
In Mozilla Bugzilla #414314, Reed Loden (reed) wrote : | #87 |
Checking in widget/
/cvsroot/
new revision: 1.101; previous revision: 1.100
done
Dave Morley (davmor2) wrote : | #88 |
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/
E [22/Feb/
E [22/Feb/
E [22/Feb/
E [22/Feb/
E [22/Feb/
E [22/Feb/
Jacob Peddicord (jpeddicord) wrote : | #89 |
Thanks for the report. Confirmed, and as far as I know this is fixed in the upcoming Beta 4.
Changed in firefox-3.0: | |
status: | New → Confirmed |
miked (miked11) wrote : | #90 |
Ubuntu Hardy Heron 8.04 Alpha4
Trying to Print WebPage on networked printer; closes browser, and cycles printer paper.
miked (miked11) wrote : | #91 |
Ubuntu Hardy Heron 8.04 Alpha4
root@tower-
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) wrote : | #92 |
Ubuntu Hardy Heron 8.04 Alpha4
root@tower-
printer local
Firefox3Pre
Click File->Print
Pop-up window appears
Under status section it reads: /usr/lib/
miked (miked11) wrote : | #93 |
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) wrote : | #94 |
Changed in firefox: | |
status: | Unknown → Fix Released |
Alexander Sack (asac) wrote : | #95 |
fix will be released with beta4
Changed in firefox-3.0: | |
importance: | Undecided → High |
milestone: | none → ubuntu-8.04 |
status: | Confirmed → Fix Committed |
Brock Williams (brock-cotcomsol) wrote : | #96 |
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) wrote : Re: [Bug 194486] Re: printing in Firefox 3 Beta 3 is broken | #97 |
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:/
> 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 -------
(856) 546-5609 home
(856) 655-3704 cell
Martin Emrich (emme) wrote : | #98 |
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) wrote : | #99 |
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:/
> 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 -------
(856) 546-5609 home
(856) 655-3704 cell
mabovo (mabovo) wrote : | #100 |
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) wrote : | #101 |
Fixed :)
Changed in firefox-3.0: | |
milestone: | ubuntu-8.04 → ubuntu-8.04-beta |
Michael Losonsky (michl) wrote : | #102 |
Strange, I don't have any problems printing in Beta 3. Using
Hardy.
Ryan Sinn (ryan-sinn) wrote : | #103 |
I didn't have any problems printing in Beta 3, but now Printing is Broken in Beta 4
Ryan Sinn (ryan-sinn) wrote : | #104 |
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) wrote : | #105 |
xulrunner-1.9 (1.9~b4+
* 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/
- drop debian/
* Update diverged patch:
- update debian/
* 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-
- update debian/rules
* Drop DEB_AUTO_
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_
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/
- update debian/
* Drop obsolete comment for extensions
- update debian/rules
* Stop build-tree/
cdbs DEB_INSTALL_
- 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/
- update debian/
* fix LP: #175904 "Firefox 3.0 makes everything annoyingly huge" by not
scaling images based on dpi.
- add debian/
- update debian/
* 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/
* 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
Changed in firefox-3.0: | |
status: | Fix Committed → Fix Released |
david wood (david-wood) wrote : | #106 |
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/
E [30/May/
Adam Gundy (adam-starsilk) wrote : | #107 |
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/
E [14/Jun/
Adam Gundy (adam-starsilk) wrote : | #108 |
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) wrote : | #109 |
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/
>
> E [14/Jun/
> 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
Changed in firefox: | |
importance: | Unknown → High |
It is a major bug for linux user with HP printers... And there are a lot of them ;)