Closed
Bug 126799
Opened 23 years ago
Closed 22 years ago
[ps] Print preview spews errors to terminal window
Categories
(Core :: Print Preview, defect, P4)
Tracking
()
VERIFIED
FIXED
mozilla1.0
People
(Reporter: bzbarsky, Assigned: roland.mainz)
References
Details
Attachments
(1 file, 4 obsolete files)
33.36 KB,
patch
|
bzbarsky
:
review+
attinasi
:
superreview+
asa
:
approval+
|
Details | Diff | Splinter Review |
BUILD: Linux 2002-02-20-08 When I open print preview, I get the following the the terminal window I started Mozilla from: lpr: lp: lp: unknown printer The same happens when closing the page setup window, trying to change zoom.
Reporter | ||
Comment 1•23 years ago
|
||
ccing rods in case this is his printsettings checkin....
Comment 2•23 years ago
|
||
Is this coming from the backend or does the frontend is needs to initialize something? I'll leave it assigned to me for now in case it's a frontend issue.
Reporter | ||
Comment 3•23 years ago
|
||
The more I think about it and look at the code, the more I suspect that the PrintSettings changes are responsible
Reporter | ||
Comment 4•23 years ago
|
||
*** Bug 126929 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 5•23 years ago
|
||
OK, I think this is a back-end bug. I'm not sure whether rods or dcone should have this... Here is what happens: 1) DocumentViewerImpl::PrintPreview calls nsDeviceContextGTK::GetDeviceContextFor 2) nsDeviceContextGTK::GetDeviceContextFor calls nsDeviceContextPS::SetSpec (I'm not using XPrint, obviously). 3) nsDeviceContextPS::SetSpec calls nsPostScriptObj::Init 4) nsPostScriptObj::Init unconditionally calls popen() on the "print command" (which is bogus in my case, hence the errors). It also opens a temp file and starts writing postscript to it (via nsPostScriptObj::begin_document) It seems incredibly wrong to me that we're opening pipes, writing to files, and so forth in print _preview_.
Reporter | ||
Comment 6•23 years ago
|
||
Oh, and we get the SIGPIPE signals while writing to the temp file, of course, which is why bug 126929 is a dup of this.
Assignee | ||
Updated•23 years ago
|
Status: NEW → ASSIGNED
Priority: -- → P2
Target Milestone: --- → mozilla0.9.9
Assignee | ||
Updated•23 years ago
|
Priority: P2 → P4
Reporter | ||
Comment 8•22 years ago
|
||
As a further comment, these SIGPIPE signals happen while we have a menu up, so mozilla has mouse focus grabbed. This means that debugging mozilla's print preview under Unix involves weird games with X displays and making sure that gdb and Mozilla are running on different displays and the like.
Assignee | ||
Updated•22 years ago
|
Target Milestone: mozilla0.9.9 → mozilla1.0
Assignee | ||
Comment 9•22 years ago
|
||
Assignee | ||
Comment 10•22 years ago
|
||
Changes: - No more unwanted empty print jobs when visiting print preview - No more uncomplete print jobs when user aborts the print job (e.g. I implemented nsDeviceContextPS::AbortDocument()) - PostScript module now uses nsCOMPtr where possible. Death to all leaks! - Added PR_LOG()-based logging. It's on even for release builds to do debugging on the customer side on demand (fix for bug 126799) - PostScript module now uses 24bit as device depth. This should avoid problems with printing SVG and other stuff in the future - Minor other cleanup (removed unused vars, functions, TABs and misc. other cleanup)
Assignee | ||
Updated•22 years ago
|
Summary: Print preview spews errors to terminal window → [ps] Print preview spews errors to terminal window
Reporter | ||
Comment 11•22 years ago
|
||
wow... that patch has a _lot_ of stuff in it that's totally irrelevant to this bug. If I read the crumbs that seem relevant correctly, we will not always open some random temp file and write some garbage to it (even in print preview). Then if we're printing for real we'll write the actual data to the file and then print that file using the print command. Is that right?
Reporter | ||
Comment 12•22 years ago
|
||
er, s/we will not always/we will now always/
Reporter | ||
Updated•22 years ago
|
Assignee | ||
Comment 13•22 years ago
|
||
Boris Zbarsky wrote: > wow... that patch has a _lot_ of stuff in it that's totally irrelevant to this > bug. It isn't "irrelevant". I simply to not want to wait a month or longer to get five or more patches "in" to get rid of all junk (incl. "random" leaks, that's why I moved all code over to use nsCOMPtr instead of the manual refcounting (Xlib and Xprint gfx code does the same since eternity)), that's all. I'd like to fix all open major regressions before filing the first patches for bug 119491 ("Cleanup global vars in PostScript and Xprint modules") ... > If I read the crumbs that seem relevant correctly, we will now always open > some random temp file and write some garbage to it (even in print preview). > Then if we're printing for real we'll write the actual data to the file and > then print that file using the print command. Is that right? Uhm uhm, not really. We create the temp. file always. Either data will be rendered with that device, storing these data in the temp. file or we do no rendering on the device. If we use the device for rendering either nsIDeviceContext::EndDocument() may be called (which starts the spooler application and feed it with the collected data) or nsIDeviceContext::AbortDocument() may be called (which discards the collected data) or we delete the device object in other ways. Using the temp. file as storage is IMHO the cleanest way to handle all cases incl. AbortDocument(). Additionally we now have a "blueprint" to get bug 6810 ("UNIX printing should set the correct title (e.g. -T option)") implemented in a clean way... The only side-effect is that we spool the file twice (we "spool" into the temp. file and the spooler command usually does spool itself when being fed from stdin; we could avoid that by using tmpnam() and pass the name of the spool file to the spooler application - but that would require to change the print command prefs, too - and I prefer tmpfile() because it _always_ (even if we crash) cleans-up after closing the last reference to the file (e.g. no dead junk files we would have to cleanup...)).
Summary: [ps] Print preview
spews errors to
terminal window → [ps] Print preview spews errors to terminal window
Assignee | ||
Comment 14•22 years ago
|
||
Attachment #73223 -
Attachment is obsolete: true
Assignee | ||
Comment 15•22 years ago
|
||
I removed the fix for bug 129655 ("[ps] PostScript module device depth is 1bit") for now per dcone's request...
Assignee | ||
Comment 16•22 years ago
|
||
Attachment #73411 -
Attachment is obsolete: true
Reporter | ||
Comment 17•22 years ago
|
||
Comment on attachment 73420 [details] [diff] [review] New patch for 2002-03-06-08-trunk per bz's review comments Looks good to me. Nice cleanup, fixes memory leaks, and definitely fixes the issues I was seeing.
Reporter | ||
Comment 18•22 years ago
|
||
Comment on attachment 73420 [details] [diff] [review] New patch for 2002-03-06-08-trunk per bz's review comments r=bzbarsky, but make sure to get an OK from rods or dcone on this
Comment 19•22 years ago
|
||
Comment on attachment 73420 [details] [diff] [review] New patch for 2002-03-06-08-trunk per bz's review comments Please take out where you are setting the depth to mDepth instead of 24 and we will make that a separate bug that we can track just that change.
Attachment #73420 -
Flags: review+
Assignee | ||
Comment 20•22 years ago
|
||
Changes: - I removed the requested change for the depth - Integrated the OpenVMS-only patch from bug 129836 ("impossible to use an alternate print command") into this one to avoid patch conflicts
Attachment #73420 -
Attachment is obsolete: true
Assignee | ||
Comment 21•22 years ago
|
||
Changes: - Fixed PR_LOG() output to print the returned depth(=24) instead of the value of |mDepth| ...
Attachment #73794 -
Attachment is obsolete: true
Reporter | ||
Comment 22•22 years ago
|
||
Comment on attachment 73805 [details] [diff] [review] New patch for 2002-03-11-08-trunk r=bzbarsky, with those minor changes
Attachment #73805 -
Flags: review+
Comment 23•22 years ago
|
||
Comment on attachment 73794 [details] [diff] [review] New patch for 2002-03-11-08-trunk r=rods
Comment 24•22 years ago
|
||
Comment on attachment 73805 [details] [diff] [review] New patch for 2002-03-11-08-trunk rs=attinasi
Attachment #73805 -
Flags: superreview+
Comment 25•22 years ago
|
||
Comment on attachment 73805 [details] [diff] [review] New patch for 2002-03-11-08-trunk a=asa (on behalf of drivers) for checkin to the 1.0 trunk
Attachment #73805 -
Flags: approval+
Assignee | ||
Comment 26•22 years ago
|
||
Fix checked in, marking bug as FIXED...
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Comment 27•22 years ago
|
||
bz/roland, please verify...
Reporter | ||
Comment 28•22 years ago
|
||
verified that mozilla now clutters up my console less.
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•