Closed
Bug 516008
Opened 15 years ago
Closed 12 years ago
Printing (via lpr) fails
Categories
(Core :: Printing: Output, defect)
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)
Comment 1•15 years ago
|
||
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.
Comment 3•15 years ago
|
||
(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
Comment 4•13 years ago
|
||
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]
Comment 5•13 years ago
|
||
A possibly related older report: bug 460318.
Closed per Whiteboard
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
Whiteboard: [closeme 2011-06-19]
You need to log in
before you can comment on or make changes to this bug.
Description
•