print to file defaults to /home and fails silently if target directory is not writable

[Rupert Levene]

Steps to reproduce:

1. Load a web page in firefox and click File->Print. The Print dialog box appears.
2. Choose Print to File from the list of printers
3. Choose home under Save in folder. (This is always the default selection for me).
4. Type a name in the filename box, and hit Print.

What happens:

The "Printing" dialog box appears, the progress indicator goes up to 100%, and then it disappears. However, no file is saved
(because /home/ is not writable).

What should happen:

A message should appear saying that the file cannot be written to /home/, and I should be returned to the Print dialog.

$ apt-cache policy firefox | head -3
firefox:
  Installed: 12.0+build1-0ubuntu0.11.10.1
  Candidate: 12.0+build1-0ubuntu0.11.10.1

[Kyle Guinn (elyk03)]

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.

[Sgautherie-bz (sgautherie-bz)]

Can you reproduce with SeaMonkey v1.1.9 ?

[Kyle Guinn (elyk03)]

(In reply to comment #1)
> Can you reproduce with SeaMonkey v1.1.9 ?
>

Yes, the bug still occurs with v1.1.9.

[Ajschult (ajschult)]

This worked with the XUL filepicker, but it seems we ignore failure when using the gtk filepicker.

[Antoine-mechelynck-gmail (antoine-mechelynck-gmail)]

(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?

[Ajschult (ajschult)]

A better workaround would be to save to a location that is writable :)

[Antoine-mechelynck-gmail (antoine-mechelynck-gmail)]

(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. :-)

[Rupert Levene (levene)]

I upgraded to 12.04, and this issue remains.

$ apt-cache policy firefox | head -3
firefox:
  Installed: 13.0+build1-0ubuntu0.12.04.1
  Candidate: 13.0+build1-0ubuntu0.12.04.1

[Rupert Levene (levene)]

This issue is still present in firefox 14:

$ apt-cache policy firefox | head -3
firefox:
  Installed: 14.0.1+build1-0ubuntu0.12.04.1
  Candidate: 14.0.1+build1-0ubuntu0.12.04.1

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Logan Rosen (logan)]

*** Bug 595461 has been marked as a duplicate of this bug. ***

[Rnicoletto (rnicoletto)]

Isn't this a DUPE of bug 245602?