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 22.214.171.124 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
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.
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 FF126.96.36.199) find the printers. I doubt that the version of GTK has any relevance here, seems that FF is not communicating with CUPS.
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
Printing is still broken in RC2. Most definitely is a show-stopper, since being able to print from FF is essential functionality.
This is also broken in the production 3.0 release running on Solaris 10 with GTK 2.10.
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.
I downloaded and compiled gtk+ 2.12.10 from source and that fixed the print dialog for me.
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"
@jws . Thank you very much in helping to get the solution to this bug known; however, from your message to debian-user, 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.  http://lists.debian.org/debian-user/2008/07/msg00523.html
How stupid of me. Yes, of course.
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.
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.
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.
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
Whiteboard: [CLOSEME 2010-09-15]
Version: unspecified → 3.0 Branch
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.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WORKSFORME
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.
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.
You need to log in before you can comment on or make changes to this bug.