583769 - Print jobs are incorrectly held until browser program exited

Status: RESOLVED INCOMPLETE

(Core :: Printing: Setup, defect)

Description

[jra]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.10) Gecko/20100506 SUSE/3.5.10-0.1 Firefox/3.5.10
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.10) Gecko/20100506 SUSE/3.5.10-0.1 Firefox/3.5.10

After upgrading from 2.0.0.16 to 3.6.8 (installed from tarball to a fresh directory, but running over already existant .mozilla profile directories), when pages are printed, the printjobs are not released to cups until the user exits the browser completely, at which time all the printed jobs release to CUPS (on SuSE 10.2).

The still-installed 2.0.0.16 works fine.

On installation, the 3.6 install displayed the description of the CUPS printer, but would never ungrey the print button; a Google search revealed this to be a common problem, with a workaround of adding

gtk-print-backends = "lpr,file"

to

/etc/opt/gnome/gtk-2.0/gtkrc

This workaround worked, but left me in the situation I'm in.  I'd be happy to have the underlying problem fixed instead, if that's easier or better known.

Oh, and you suck.  :-)



Reproducible: Always

Steps to Reproduce:
1. Start browser
2. Load a page
3. Print that page
4. Observe no output from printer
5. Close browser
6. Now observe the expected output from the printer.
Actual Results:  
See step 6.  Why is this actually a separate box?  :-)

Expected Results:  
See also step 6.

(As extra information: TB 3.1.1, installed from tarball at the same time, displays the same "print button greyed out" failure, and the gtkrc mod apparently is *not* seen by it.)

And yes, "printing" should be a Firefox component, but I see there's already a bug open on that.

Comment 1

[jra]

Build ID Correction: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8  (the one listed above is from my reporting laptop, and I forgot to change it before submitting.)

Comment 2

[jra]

I have not been able to find a workaround for this problem; several older workarounds to patch kprinter in as a replacement target program do not work, though manually specifying kprinter to replace lpr in the gtk print dialog *does* pop the kprinter UI.

The print job, though, *still* does not come out until the browser is closed.

I am clearly not the only one having this problem; I cannot fathom how "web browser can't print" could make it through a regression test suite.  I don't know whom to blame, here: Mozilla (who keep diking out useful functionality), SuSE, or KDE (though KDE's fault lies more in removing kprinter from KDE4, which -- while it will affect me WRT this bug, is not doing so on the install which caused this report).

Since the initial symptom was "can't even click the print button", I'll assume it's Mozilla's fault to start with.  :-)

Comment 3

[Kevin Brosnan]

Firefox only uses the GTK print dialog in Firefox 3.0 and later. Any hacks you use to get printing through Kprinter is your own responsibility.

Comment 4

[jra]

I appreciate the comment, Kevin, but note that the kprinter stuff is a report of an attempted workaround; the actual *bug* is as in the description, for which kprinter is a red herring.

Firefox 3 will print using its default print dialog and configuration under Suse 10.2, but not until the FF binary for that user exits.

Comment 5

[jra]

This bug has now been reproduced in 4.0b7, on the same install:

SuSE 10.2
Kernel 2.6.18.8

printing to lpr, with the system printer set up as lpr's default.

Print jobs are still not released until the program exits -- and every time I try to exit it, it crashes out to the crash reporter; you'll find several reports under my email address from just now.  The print job is finally released, but not until *the crash reporter* is quit from; restarting FF from the crash reporter does not release the print job either.

The print subsystem on this machine is cups 1.2.7.

I'm open to any workaround suggestions that might clear this problem; it would be nice to be able to get my client off of FF2.0.

If someone can make a defensible argument that it's due to some specific old component of the OS, I'll try to sell them on the entire billable day that an OS upgrade will take.

Comment 6

[timeless]

jra, please read:

https://bugzilla.mozilla.org/page.cgi?id=fields.html#importance
and
https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

you'll probably need to find someone who can explain what lpr is doing. perhaps lpr has a mode where it can indicate what input it has seen. (strace of lpr? but don't give it to us, we don't speak lpr)

Comment 7

[jra]

It's not clear, timeless, what your links are in reply to, but "importance" not only isn't an anchor on that page, the field isn't *described* on that page.

I'm giving up; I'm going to do the 11.4 OS upgrade for them.

Comment 8

[Petruta Horea [:phorea], Desktop Test Engineering]

Closing this as Incomplete since its been a long time since the last update on this issue and the reporter's account is disabled.
Printing works on latest Firefox / latest Ubuntu versions.