If a user tries to download and save a file in a web application, the prompt will appear to allow a user to open or save the respective file. If they select save, the file should be saved to the downloads folder for each respective OS (e.g. Win 7 in user/downloads). The current behavior however is different - nothing happens. You are unable to save a downloaded file to your machine. Test case I used (application referencing this will be hosted soon): 1. Go to http://mozqa.com/data/firefox/downloading/ within a web application 2. Try downloading one of the unknown types 3. Select save Expected: The file should be saved to the user's downloads folder in respect to each OS's downloads folder location. Actual: No file is saved to the user's downloads folder.

The impact of this bug affects app functionality such as export to X format style functionality. Example: Anything to do with exporting in google docs. Likely to happen with any web apps that are project management based. Strangely enough, if prompted to save the file, if you open the file, you can successfully open the file.

Note - This affects functionality in box, a top app. Re-marking it for triage, since it affects a top app now.

My vote is to not block on this and to make it a marketplace-beta=. It's 1 top app if this issue were a high percentage of top apps I'd want more discussion.

(In reply to Jennifer Arguello :ticachica from comment #3) > My vote is to not block on this and to make it a marketplace-beta=. It's 1 > top app if this issue were a high percentage of top apps I'd want more > discussion. Sounds good. I'll keep a look out if this happens more frequently.

With this particular testcase, it works now because the file being downloaded is hosted on a different domain, so the url gets handed by the default browser to download. http://mozqa.com/data/firefox/downloading/

Trying to save a file from the same domain results in this exception: WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x8000FFFF: file mozilla-central/toolkit/components/downloads/nsDownloadManager.cpp, line 1278 ************************************************************ * Call to xpconnect wrapped JSObject produced this error: * [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIHelperAppLauncher.saveToDisk]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: components/nsHelperAppDlg.js :: <TOP_LEVEL> :: line 459" data: no]

However, if you open the file instead of trying to save the file, downloading works.

(In reply to Edward Lee :Mardak from comment #7) > However, if you open the file instead of trying to save the file, > downloading works. Right, I can confirm that behavior as well. Open works on my machine, but not save.

Default downloads to the Downloads directory set by the platform just like Firefox.

The patch lets files to be saved to disk (into the default downloads directory), however there's no UI or download management interface.

(In reply to Edward Lee :Mardak from comment #10) > The patch lets files to be saved to disk (into the default downloads > directory), however there's no UI or download management interface. That's acceptable to fix this bug. As for UI improvements, we can track that in a separate bug if need be.

Comment on attachment 619649 [details] [diff] [review] v1 Looks good, works as expected, r=myk!