Last Comment Bug 430818 - Unable to print: Print dialog shows no printers and does not offer PostScript File choice
: Unable to print: Print dialog shows no printers and does not offer PostScript...
Status: RESOLVED WORKSFORME
[CLOSEME 2010-09-15]
:
Product: Firefox
Classification: Client Software
Component: General (show other bugs)
: 3.0 Branch
: x86 Linux
: -- normal with 1 vote (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-04-25 09:37 PDT by David F. Skoll
Modified: 2012-11-10 13:46 PST (History)
8 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description David F. Skoll 2008-04-25 09:37:20 PDT
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5) Gecko/2008032619 Firefox/3.0b5
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5) Gecko/2008032619 Firefox/3.0b5

Firefox 3.0b5 on Debian Etch under XFCE.  Hitting File : Print pops up a printer dialog with no printers listed and the "Print" button disabled.  There is no way to even generate PostScript!  Firefox 2.0.0.10 on the same machine prints just fine.

Note: I installed a private copy of gtk+ 2.10 in /opt/gtk-2.10.

Reproducible: Always

Steps to Reproduce:
1. Try to print
2. Useless dialog comes up
Comment 1 David F. Skoll 2008-04-25 10:49:37 PDT
Actually, I think the culprit may be a broken/messed-up installation of gtk+ 2.10.  :-(

It's too bad you require a version of gtk+ newer than ships with Etch.  It makes using FF3 quite difficult.

Regards,

David.
Comment 2 Alex Fisher 2008-05-21 03:11:41 PDT
same problem occurs using FF rc1 on Mandriva 2008.1 64 bi, Athlon 64 3200+, 2 GB RAM, all latest updates (including 32-bit libraries). attept to print, empty dialog as in the original report, Print button disables and no way to find/add existing printers (all other apps, including FF2.0.0.13) find the printers. 

I doubt that the version of GTK has any relevance here, seems that FF is not communicating with CUPS.
Comment 3 David F. Skoll 2008-05-26 13:55:53 PDT
This is NOT FIXED in the 3.0 release candidate!  It's a real show-stopper...
Screenshot of print dialog here:

http://www.roaringpenguin.com/cf7a8cd73d67435e02e8bc439d7e04e0d6867a7d.png
Comment 4 Alex Fisher 2008-06-07 23:12:27 PDT
Printing is still broken in RC2. Most definitely is a show-stopper, since being able to print from FF is essential functionality.
Comment 5 sean walmsley 2008-07-06 07:58:36 PDT
This is also broken in the production 3.0 release running on Solaris 10 with GTK 2.10.
Comment 6 Mumia W. 2008-07-06 10:04:24 PDT
The print dialog is populated on my FX 3.0rc2 (Linux). I'm using Debian Etch, which contains gtk+2.8, so I had to build and install gtk+2.10 myself. My print dialog has both entries for "print to file" and "print to LPR."

I have lprng 3.8.28 installed; however, my /etc/printcap was created by the original lpr program before it was removed from Debian. Lprng doesn't seem to create, by default, an /etc/printcap. I do not have CUPS installed.
Comment 7 David F. Skoll 2008-07-06 13:11:27 PDT
I downloaded and compiled gtk+ 2.12.10 from source and that fixed the print dialog for me.
Comment 8 jws 2008-07-08 02:05:58 PDT
It seems to be a problem with the gtk settings, not a bug in firefox. See Debian bug #489765. You have to put in ~/.gtkrc-2.0 :

"file,lpr,cups"
Comment 9 Mumia W. 2008-07-08 09:19:56 PDT
@jws . Thank you very much in helping to get the solution to this bug known; however, from your message to debian-user[0], I think you mean this should go into ~/.gtkrc-2.0:

gtk-print-backends = "file,lpr,cups"

BTW, I booted into Ubuntu Hardy and discovered the bug that everyone was talking about, and when I made the change you suggested, the LPR option in the print dialog returned in Firefox-3.0.

[0] http://lists.debian.org/debian-user/2008/07/msg00523.html
Comment 10 jws 2008-07-08 09:48:28 PDT
How stupid of me. Yes, of course.
Comment 11 Alex Fisher 2008-07-08 15:00:02 PDT
Modifications to gtkrc make no difference. Firefox 3.0 Release still has no printers or other options in the print dialog. It seems that the workaround may only apply to Debian-based distros.

I use KDE 3, have the most up to date GTK available from Mandriva, use CUPS for printing. I will try two other things - First, I'll log out and restart the dm, then if that still doesn't work I'll try logging out and log in to GNOME.

This may also explain why there seem to be no RPM packages available yet.
Comment 12 sean walmsley 2008-07-08 15:38:24 PDT
Using the Sun contributed 3.0 build for Solaris 10 (SPARC), I was able to get "print to file" and "print to LPR" working by:

- setting GTK_PATH to $DIST/depend/lib/gtk-2.0 in the run-mozilla.sh script where $DIST is the FF3 installation directory. This allows GTK to find the various shared libraries in the printbackends subdirectory (e.g. libprintbackend-lpr.so)
- removing the libprintbackend-papi.so library from the printbackends directory because its presence seems to cause FF3 to hang or crash when you try to print

I think that the problem was that the Solaris FF3 distribution includes some updated GTK components that are installed in a non-standard location, and GTK wasn't picking up the print libraries from this location. I have not idea what the problem with the PAPI library is, but I can live with lpr printing for now.
Comment 13 Mike Beltzner [:beltzner, not reading bugmail] 2008-11-09 22:59:21 PST
Clearing blocking flag, as discussion in this bug leads me to wonder if this is RESO INVALID due to it being due to various oddities in Linux configs.
Comment 14 Tyler Downer [:Tyler] 2010-08-30 22:19:44 PDT
Reporter, are you still seeing this issue with Firefox 3.6.x or later in safe mode? If not, please close. These links can help you in your testing.
http://support.mozilla.com/kb/Safe+Mode
http://support.mozilla.com/kb/Managing+profiles
Comment 15 David F. Skoll 2010-09-01 12:51:57 PDT
I am no longer seeing this bug.  I have since upgraded to Debian Lenny and it
works fine.  I suspect the original problem was caused by a broken gtk installation.

I think you can close this bug.

Regards,

David.
Comment 16 Simon A. Eugster 2011-09-23 13:35:38 PDT
I'm on aptosid 64-bit (which is more or less Debian sid). Still had the problem with firefox downloaded from mozilla.org (not iceweasel). Strace gave me the following output:
$ strace firefox 2>&1 |grep print
[...]
access("/home/simon/.gtk-2.0/2.10.0/i486-pc-linux-gnu/printbackends/libprintbackend-file.so", F_OK) = -1 ENOENT (No such file or directory)
access("/home/simon/.gtk-2.0/2.10.0/i486-pc-linux-gnu/printbackends/libprintbackend-file.la", F_OK) = -1 ENOENT (No such file or directory)
access("/home/simon/.gtk-2.0/2.10.0/printbackends/libprintbackend-file.so", F_OK) = -1 ENOENT (No such file or directory)
access("/home/simon/.gtk-2.0/2.10.0/printbackends/libprintbackend-file.la", F_OK) = -1 ENOENT (No such file or directory)
access("/home/simon/.gtk-2.0/i486-pc-linux-gnu/printbackends/libprintbackend-file.so", F_OK) = -1 ENOENT (No such file or directory)
access("/home/simon/.gtk-2.0/i486-pc-linux-gnu/printbackends/libprintbackend-file.la", F_OK) = -1 ENOENT (No such file or directory)
access("/home/simon/.gtk-2.0/printbackends/libprintbackend-file.so", F_OK) = -1 ENOENT (No such file or directory)
access("/home/simon/.gtk-2.0/printbackends/libprintbackend-file.la", F_OK) = -1 ENOENT (No such file or directory)
access("/usr/lib/gtk-2.0/2.10.0/i486-pc-linux-gnu/printbackends/libprintbackend-file.so", F_OK) = -1 ENOENT (No such file or directory)
access("/usr/lib/gtk-2.0/2.10.0/i486-pc-linux-gnu/printbackends/libprintbackend-file.la", F_OK) = -1 ENOENT (No such file or directory)
access("/usr/lib/gtk-2.0/2.10.0/printbackends/libprintbackend-file.so", F_OK) = -1 ENOENT (No such file or directory)
access("/usr/lib/gtk-2.0/2.10.0/printbackends/libprintbackend-file.la", F_OK) = -1 ENOENT (No such file or directory)
access("/usr/lib/gtk-2.0/i486-pc-linux-gnu/printbackends/libprintbackend-file.so", F_OK) = -1 ENOENT (No such file or directory)
access("/usr/lib/gtk-2.0/i486-pc-linux-gnu/printbackends/libprintbackend-file.la", F_OK) = -1 ENOENT (No such file or directory)
access("/usr/lib/gtk-2.0/printbackends/libprintbackend-file.so", F_OK) = -1 ENOENT (No such file or directory)
access("/usr/lib/gtk-2.0/printbackends/libprintbackend-file.la", F_OK) = -1 ENOENT (No such file or directory)

So the libprintbackend were nowhere. However they are just in /usr/lib32:
$ mlocate libprintbackend-lpr.so
/usr/lib/gtk-3.0/3.0.0/printbackends/libprintbackend-lpr.so
/usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/printbackends/libprintbackend-lpr.so
/usr/lib32/gtk-2.0/2.10.0/printbackends/libprintbackend-lpr.so

After linking the 32-bit directory, the printers finally show up, also in other 32-bit programs like Celtx!
# cd /usr/lib/gtk-2.0/2.10.0/
# ls
engines
# ln -s /usr/lib32/gtk-2.0/2.10.0/printbackends/

Firefox 6.0.2, by the way.
Comment 17 quixote7 2012-11-10 13:46:03 PST
I had the same problem: firefox not finding the 32-bit printbackends it needs, so no options to print at all, not even to file. I'm using 64-bit LinuxMint Debian Squeeze and (I'm 99% sure) a 64-bit Firefox 14.0.1.

Simon (comment 16) very kindly gave me a few more pointers so I was able to apply his workaround. These are the steps I followed:
(Install strace, which wasn't on my system. sudo apt-get install strace)
$strace firefox 2>&1 | grep "print"
that command starts firefox. In order to get messages about printing, start file > print in Firefox.
In my case, the relevant lines were:
access("/usr/lib/gtk-2.0/printbackends/libprintbackend-file.so", F_OK) = -1 ENOENT (No such file or directory)
access("/usr/lib/gtk-2.0/printbackends/libprintbackend-lpr.so", F_OK) = -1 ENOENT (No such file or directory)
access("/usr/lib/gtk-2.0/printbackends/libprintbackend-cups.so", F_OK) = -1 ENOENT (No such file or directory)

As on his system, the necessary files were all in /usr/lib32/gtk-2.0/2.10.0/printbackends/
(Note: /usr/lib<strong>32</strong>, whereas FF is looking in /usr/lib.)
So, as he says, switch to /usr/lib/gtk-2.0/printbackends/ and make the link to /usr/lib32/gtk-2.0/2.10.0/printbackends/

And, W00T!, all the printers are finally there again.

Note You need to log in before you can comment on or make changes to this bug.