245602 - No error message if printing to a file in non-existent directory

Status: NEW

(Core :: Printing: Output, defect)

Description

[Davor Cubranic]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031029
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031029

When I choose printing to file, if one of the directories in the path does not
exist, Mozilla does not give any error messages but simply closes the print
dialog as if everything worked fine.

Reproducible: Always
Steps to Reproduce:
1. Open a page
2. Select Print, to file, e.g., /.tmp/mozilla.ps (if directory /.tmp does not exist)
Actual Results:  
Nothing. Mozilla closes the print dialog and does not signal the error.

Expected Results:  
Some kind of error dialog.

Comment 1

[Kenneth Herron]

Confirming. This is probably due to the nsPrintJobPS changes. Previously, during
print-to-file, the final destination file was opened when the PS module was
initialized; now it isn't opened until the print job has been fully formatted
into a temporary file. It appears that printing errors late in the print job
(specifically, at the EndDocument() stage) aren't being communicated to the user.

Comment 2

[Kenneth Herron]

More accurately, the PS module used to open the final output file during the
call to nsDeviceContextPS::SetSpec(); now the PS module opens the final output
file during the call to nsDeviceContextPS::EndDocument().

Farther up the call stack, the whole printing process is being run by an
nsPrintEngine object (content/base/nsPrintEngine.cpp). nsPrintEngine creates the
print device context within nsPrintEngine::Print(), however the pointer to this
object is stored inside a child nsPrintData object. The nsPrintData destructor
later calls ::EndDocument() before deleting the print device context. 
nsPrintEngine has a function to display an error dialog for problems, but
nsPrintData doesn't, so there's no simple way to display EndDocument() errors.

the simplest fix might be to store a weak reference to the nsPrintEngine object
in its nsPrintData object, so that nsPrintData can call the print error dialog
function. A perhaps cleaner fix might be to move the logic for cleaning up the
print device context--calling EndDocument() and so on--out of the nsPrintData
dtor and into nsPrintEngine.

CC'ing a couple of content people in hopes of guidance.

Comment 3

[Johnny Stenback (:jst)]

Sounds reasonable to me, but IMO the earlier we can report this error the
better. No point in generating PS data if we won't have anyplace to put it etc.

Comment 4

[Michael Kohler [:mkohler]]

This is a mass change. Every comment has "assigned-to-new" in it.

I didn't look through the bugs, so I'm sorry if I change a bug which shouldn't be changed. But I guess these bugs are just bugs that were once assigned and people forgot to change the Status back when unassigning.