Open
Bug 415023
Opened 17 years ago
Updated 2 years ago
Print to file fails silently when permission denied
Categories
(Core :: Printing: Output, defect)
Tracking
()
NEW
People
(Reporter: elyk03, Unassigned)
References
Details
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.4) Gecko/20070601 SeaMonkey/1.1.2 Mnenhy/0.7.4.0
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.4) Gecko/20070601 SeaMonkey/1.1.2 Mnenhy/0.7.4.0
Printing a webpage to a postscript file in a directory where the user does not have write privileges gives no feedback that the operation failed. No file is created, and no "Permission Denied" warning message occurs.
Reproducible: Always
Steps to Reproduce:
1. Open any webpage.
2. Go to File->Print
3. Select PostScript/default and the "Print to File" checkbox, then print.
4. When prompted for the filename, select a directory where you don't have write permission (e.g. /).
Actual Results:
It goes through the motion of printing to file, but no file is created and no warning message occurs.
Expected Results:
The program should prompt the user immediately that permission is denied.
Comment 1•17 years ago
|
||
Can you reproduce with SeaMonkey v1.1.9 ?
Version: unspecified → SeaMonkey 1.1 Branch
Reporter | ||
Comment 2•17 years ago
|
||
(In reply to comment #1)
> Can you reproduce with SeaMonkey v1.1.9 ?
>
Yes, the bug still occurs with v1.1.9.
Comment 3•17 years ago
|
||
This worked with the XUL filepicker, but it seems we ignore failure when using the gtk filepicker.
Assignee: general → nobody
Status: UNCONFIRMED → NEW
Component: General → Printing
Ever confirmed: true
Product: Mozilla Application Suite → Core
QA Contact: general → printing
Version: SeaMonkey 1.1 Branch → Trunk
Comment 4•17 years ago
|
||
(In reply to comment #3)
> This worked with the XUL filepicker, but it seems we ignore failure when using
> the gtk filepicker.
>
IOW, a workaround would be setting ui.allow_platform_file_picker to false in about:config?
Comment 5•17 years ago
|
||
A better workaround would be to save to a location that is writable :)
Comment 6•17 years ago
|
||
(In reply to comment #5)
> A better workaround would be to save to a location that is writable :)
>
Of course, but this bug is all about getting no error when you thought it was writable, and it fact it isn't. :-)
See Also: → https://launchpad.net/bugs/1004569
Comment 8•12 years ago
|
||
Isn't this a DUPE of bug 245602?
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•