User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20100101 Firefox/7.0.1 Build ID: 20110928221813 Steps to reproduce: I clicked in a download link and tryed to save the file in a folder whose write permission I do not have. Actual results: When clicking in a download link and the save pop-up appears, if you navigate to a folder where your user don't have permission to write or if the folder is mounted read-only, Firefox does not save the file, does not report any error message and does act as the file was properly saved. Some downloads are paid and this loss of data may cause problems, because a second click in the link is needed and the download process must be restarted. Expected results: Before trying to save the file, Firefox should have investigated the folder and should report useful error messages, like "You don't have permission to write there!" or "This file-system is mounted read-only!", so the user has the change to navigate to another folder and try to save the file again. By doing so, no file will be lost and download will never fail.
Is there anything in the tools->web developer->Error console?
I can reproduce this on Linux. I get a proper error message that the download failed due to permissions only when saving via Save page as, and also Save link target as. But when the download is initiated via normal click on a link (try e.g. https://www.kernel.org and choose a patch file there). There is no indication of download (not in the Download manager) and no error message. The download is ignored.
Yes!! I reached this bug while using Ubuntu Linux 10.10 and Firefox 7 (sorry, I never tried it under others OS). The Download is totally ignored and the Download window does never open.
Thanks for your explanation. I have made the dependence on your bug 567585. We will see if it helps this problem. Thanks for looking into those parts of code.
Additional observation. 10.02 (under linux: ) Using [File] -> [Save as] If I set the default download directory to a directory without write-permission in advance, FF seems to silently fails to write to the directory, BUT resets the default directory to the ~/Download or whatever is the build default of FF and happily writes to the directory(!) The default download directory location is reset to the built-in default when this happens. Hmm... I am not sure if this under-the-hood recovery without warning at all is a good idea. (After all the user made a choice.) Right clicking on a link, and choose the "save as" from the pop-up context menu and chooses a write-protected directory to save the file fails SILENTLY as reported before. Now, under WINDOWS, but it seems that the write-only property on local disk file system (at least this is I can test easily) seems to be ignored by mozilla I/O library (presumably if the user has admin permission. I never failed to write to a directory no matter what I do using attrib under Windows console, or chmod in cygwin console to set the write-protected property of a directory.) This may be a problem, though, from a security point of view. OH, wait, under windows, if I create a directory, and then sets the write-permission status as attrib or chmod (under cygwin), it seems that ONLY the FILES created BELOW that directory seem to be set to READ-only. We can still create a file under it (I was checking the PROPERTIES of the directory using windows GUI and noticed this. The modification property of the directory seems to be still available to users. But this may be due to the user accounts on my Windows PC have administrative privildge.) At least my last observation explains why we have seen less such reporting of write-protected directory causing problems coming from Windows users in contrast to linux/solaris/etc. users who have suffered and reported these problems including myself. Presumably, even windows users will experience the same problem when they try to write to a write-protected file server. Someone more familiar with Windows ACL setting can disable the write to a directory completely and check how FF (and TB) operates under the windows. .