Closed Bug 516008 Opened 15 years ago Closed 12 years ago

Printing (via lpr) fails

Categories

(Core :: Printing: Output, defect)

1.9.0 Branch
x86
Linux
defect
Not set
major

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: T.Crane, Unassigned)

References

()

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.13) Gecko/2009073021 Firefox/3.0.13
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.13) Gecko/2009073021 Firefox/3.0.13

When attempting to print (any webpage) Firefox hangs. For printing I am running BSD lpr/lpd rather than cups and have the following line in my /etc/gtk-2.0/gtkrc file;

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

stracing firefox shows it loads this information from the file but still appears to be accessing cups related stuff. eg., 

25729 open("/usr/lib/firefox-3.0.13/libcups.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
25729 open("/usr/lib/firefox-3.0.13/plugins/libcups.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
25729 open("/usr/X11R6/lib/libcups.so.2", O_RDONLY) = 41
25729 open("/home/tom/.cupsrc", O_RDONLY) = -1 ENOENT (No such file or directory)
25729 open("/etc/cups/client.conf", O_RDONLY) = 41
25729 read(41, "#\n# \"$Id: client.conf,v 1.9 2005/01/03 19:29:45 mike Exp $\"\n#\n#   Sample client configuration file for the Common UNIX P$
25729 open("/home/tom/.cupsrc", O_RDONLY) = -1 ENOENT (No such file or directory)
25729 open("/etc/cups/client.conf", O_RDONLY) = 41
25729 read(41, "#\n# \"$Id: client.conf,v 1.9 2005/01/03 19:29:45 mike Exp $\"\n#\n#   Sample client configuration file for the Common UNIX P$
25729 access("/usr/share/locale/en_GB/cups_en_GB", F_OK) = -1 ENOENT (No such file or directory)
25729 access("/usr/share/locale/en/cups_en", F_OK) = 0
25729 open("/usr/share/locale/en/cups_en", O_RDONLY) = 42

I have not changed my gtk config since moving from v. 3.0.12 to 3.0.13.

When in the hung state Firefox repeatedly connects to the ipp tcp port (631).  strace shows;

25729 socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 41
25729 fcntl64(41, F_SETFD, FD_CLOEXEC)  = 0
25729 setsockopt(41, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
25729 setsockopt(41, SOL_TCP, TCP_NODELAY, [1], 4) = 0
25729 connect(41, {sa_family=AF_INET, sin_port=htons(631), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
25729 send(41, "POST / HTTP/1.1\r\n", 17, 0) = 17
25729 send(41, "Content-Length: 138\r\n", 21, 0) = 21
25729 send(41, "Content-Type: application/ipp\r\n", 31, 0) = 31
25729 send(41, "Host: localhost\r\n", 17, 0) = 17
25729 send(41, "\r\n", 2, 0)            = 2
25729 time(NULL)                        = 1252684945
25729 send(41, "\1\1@\2\0\0\0\1", 8, 0) = 8
25729 time(NULL)                        = 1252684945
25729 send(41, "\1G\0\22attributes-charset\0\viso-8859-15", 35, 0) = 35
25729 time(NULL)                        = 1252684945
25729 send(41, "H\0\33attributes-natural-language\0\2en", 34, 0) = 34
25729 time(NULL)                        = 1252684945
25729 send(41, "D\0\24requested-attributes\0\fprinter-nameD\0\0\0\22job-sheets-default", 60, 0) = 60
25729 time(NULL)                        = 1252684945
25729 send(41, "\3", 1, 0)              = 1
25729 recv(41, "", 2048, 0)             = 0
25729 close(41)                         = 0

I tried running Firefox from the command line to look for error messages but there were none.

Cheers
Tom.

Reproducible: Always

Steps to Reproduce:
1. Load Firefox
2. Access the <File> -> <Print> menu

Actual Results:  
hang as described above

Expected Results:  
Prints the job

System details:

OS: Slackware Linux 11.0
Kernel: 2.6.20
gtk version: 1.2.10
package: ftp://ftp.slackware.com/pub/slackware/slackware-12.2/patches/packages/mozilla-firefox-3.0.13-i686-1.tgz (and is recommended for Slackware 11.0 and above)
Tom -- thanks for the report!

Would you mind trying the Mozilla stock 3.0.12 vs 3.0.13 builds, just to confirm that you *can't* reproduce the problem in stock 3.0.12, but *can* in stock 3.0.13?

Links here:
http://releases.mozilla.org/pub/mozilla.org/firefox/releases/3.0.12/linux-i686/en-US/
http://releases.mozilla.org/pub/mozilla.org/firefox/releases/3.0.13/linux-i686/en-US/
Component: General → Printing: Output
Product: Firefox → Core
QA Contact: general → printing
Version: unspecified → 1.9.0 Branch
Many thanks for the followup Daniel.  I've tried the above but the problem is now present with 3.0.12 :-(.  Ditto 3.0.14.  The problem must lie elsewhere.  I am going to try building (ver. 3.0.14) from source and see if there is any mileage in that approach.  A suspect the problem is in the Mozilla/gtk interface or maybe entirely within gtk.  I have started a build with;

./configure --prefix =<installdir> \
        --enable-debug             \
        --enable-application=browser --enable-static
make

Does this look suitable or are there any other options which might help me?

Any other suggestions I might try for probing the problem?

BTW: The above link for ver 3.0.12 is broken.  I found ftp://ftp.mozilla.org/pub/firefox/releases/3.0.12/source/firefox-3.0.12-source.tar.bz2
worked instead.

Cheers
Tom.
(In reply to comment #2)
> Many thanks for the followup Daniel.  I've tried the above but the problem is
> now present with 3.0.12 :-(.  Ditto 3.0.14.  The problem must lie elsewhere.

Ok -- updating bug summary to indicate that 3.0.12/3.0.13 isn't the problem.

> I have started a build with;
> 
> ./configure --prefix =<installdir> \

I wouldn't recommend manually invoking configure -- generally "make -f client.mk build" is what you want to do.

Not great to discuss build instructions/problems on a bug, though -- see these wiki pages, and join #developers on irc.mozilla.org if you have questions.
https://developer.mozilla.org/En/Developer_Guide/Build_Instructions and 
in particular https://developer.mozilla.org/en/Build_and_Install

> Any other suggestions I might try for probing the problem?

I'd recommend trying to track down a regression range, if this is indeed a regression in Firefox (i.e. if this did used to work with some past version of Firefox).

http://quality.mozilla.org/documents-home/bugs-docs/bug-triaging-guidelines/finding-regression-windows

Again, ask in #developers if you have questions.

> BTW: The above link for ver 3.0.12 is broken.

Yeah -- the 3.0.12 release has been removed, I guess, since it's outdated now.  You can still get nightly builds of Firefox 3.0.x code by looking for "mozilla1.9.0" folders in http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/  (and the per-year/per-month subfolders linked there)
Summary: Printing (via lpr) fails after upgrading 3.0.12 to 3.0.13 → Printing (via lpr) fails
reporter, does this still fail when using Firefox 5 *beta* http://www.mozilla.com/en-US/firefox/channel/ or Firefox 4?
Whiteboard: [closeme 2011-06-19]
A possibly related older report: bug 460318.
Closed per Whiteboard
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
Whiteboard: [closeme 2011-06-19]
Resolution: WORKSFORME → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.