Firefox 2.0.6 handles downloads different than Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007090411 Minefield/3.0a8pre ID:2007090411 repro: Go to Toolt->Options->Main set Show the Downloads window downloading a file [V] (0) Always ask me where to save files FF2.0.6 e.g. go to http://hourly-archive.localgho.st/ (plenty of downloads there). click on a zip select C:/windows/X in the filepicker rightclick saveas on a zip and select C:/windows/Y in the filepicker click on a zip, the filepicker opens C:/windows/X rightclick saveas on a zip, the the filepicker opens C:/windows/Y FF3.0a8pre click on a zip select C:/windows/X in the filepicker rightclick saveas on a zip and select C:/windows/Y in the filepicker click on a zip, the filepicker opens C:/windows/Y (<- wrong), change it to C:/windows/X rightclick saveas on a zip, the filepicker opens C:/windows/X (<- wrong), you need to change it again. In FF2.0.6 both browser.download.dir (default for save) and browser.download.lastDir (default for saveas) are respected In FF3.08pre only browser.download.lastDir is respected so save and saveas go to the same directory.

It seems you're asking for two seperate download folder preferences. One for right click, save-as and one for click, save as. Why should we treat those two operations differently when choosing a default folder to display in the file picker when saving a file?

(In reply to comment #1) > It seems you're asking for two seperate download folder preferences. One for > right click, save-as and one for click, save as. Why should we treat those two > operations differently when choosing a default folder to display in the file > picker when saving a file? > I know it's a lame answer, but because it's always been like that on branch. If everyone agrees that the current behaviour on branch (FF2.0.6) is "wrong" and/or "unexpected" than this bug should be marked WONTFIX.

(In reply to comment #2) > If everyone agrees that the current behaviour on branch (FF2.0.6) is "wrong" > and/or "unexpected" than this bug should be marked WONTFIX. See bug 255379 and its duplicates, though of couse this doesn't mean that everyone agrees to this.

I'm going to try to work up a summary of where everything is sent and post it here so we can discuss the current behavior. This is pretty important and obviously, there are a lot of opinions on how things should work. In the past it seems there's been a lot of confusion over downoad prefs, default directories, etc.. In the end it would be nice if we could standardize on a set behavior that everyone is aware of and happy with.

Download Manager Service: ------------------------- 1) defaultDownloadFolder (attribute) - Does not create folder when called OSX: Safari download folder or Desktop/Downloads Vista: User/Downloads XP/2K: Desktop/Downloads Linux: Home/Downloads 2) usersDownloadFolder (attribute) - Based on browser.download.folderList pref - Will create folder if needed OSX: 0 -> Desktop (default) 1 -> defaultDownloadFolder 2 -> browser.download.dir* Vista: 0 -> Desktop 1 -> defaultDownloadFolder (default) 2 -> browser.download.dir* XP/2K: 0 -> Desktop (default) 1 -> defaultDownloadFolder 2 -> browser.download.dir* Linux: 0 -> Home (default) 1 -> defaultDownloadFolder 2 -> browser.download.dir* * If browser.download.dir does not exist and can not be created, defaults to defaultDownloadFolder and will update browser.download.dir accordingly when called. Firefox Behavior: ----------------- browser.download.useDownloadFolder = true Content area context menu file pickers: Save Image As - usersDownloadFolder Save Link As - usersDownloadFolder Save Page As - usersDownloadFolder Unknown content dialog save as: - usersDownloadFolder (no filepicker prompt) Download Manager window drag and drop: - usersDownloadFolder (no filepicker prompt) browser.download.useDownloadFolder = false Content area context menu file pickers: Save Image As - lastDir* Save Link As - lastDir* Save Page As - lastDir* Unknown content dialog save as: - lastDir* (filepicker prompt) Download Manager window drag and drop: - lastDir* (filepicker prompt) * If lastDir points to a non-existent directory, defaults to usersDownloadFolder.

Please let me know if any of this is innacturate based on the latest in trunk (I tested off a checkout from this morning, Sept 5th.) The option here, based on this feature request in this bug, would be to create lastDir prefs for each of the save link, image, and page context menu options when the useDownloadFolder pref is set to false. Personally I feel that will be confusing to users, although I recognize why power users might appreciate the option.

where is "browser.download.useDownloadFolder" ? have to create myself ? my setting, see attachment. [with right-click "Save ..."] before check-in for #393247 1) save a file in [A] folder 2) next time, file picker always open [A] folder (last saved folder). after check-in 1) save a file in [A] folder 2) next time, file picker always open "Desktop". so I have to reselect a folder to save. [with left-click](no problem) files are downloaded to desktop. (according to setting)

My apologies, it's useDownloadDir. Updated - Download Manager Service: ------------------------- 1) defaultDownloadFolder (attribute) - Does not create folder when called OSX: Safari download folder or Desktop/Downloads Vista: User/Downloads XP/2K: Desktop/Downloads Linux: Home/Downloads 2) usersDownloadFolder (attribute) - Based on browser.download.folderList pref - Will create folder if needed OSX: 0 -> Desktop (default) 1 -> defaultDownloadFolder 2 -> browser.download.dir* Vista: 0 -> Desktop 1 -> defaultDownloadFolder (default) 2 -> browser.download.dir* XP/2K: 0 -> Desktop (default) 1 -> defaultDownloadFolder 2 -> browser.download.dir* Linux: 0 -> Home (default) 1 -> defaultDownloadFolder 2 -> browser.download.dir* * If browser.download.dir does not exist and can not be created, defaults to defaultDownloadFolder and will update browser.download.dir accordingly when called. Firefox Behavior: ----------------- browser.download.useDownloadDir = true Content area context menu file pickers: Save Image As - usersDownloadFolder Save Link As - usersDownloadFolder Save Page As - usersDownloadFolder Unknown content dialog save as: - usersDownloadFolder (no filepicker prompt) Download Manager window drag and drop: - usersDownloadFolder (no filepicker prompt) browser.download.useDownloadDir = false Content area context menu file pickers: Save Image As - lastDir* Save Link As - lastDir* Save Page As - lastDir* Unknown content dialog save as: - lastDir* (filepicker prompt) Download Manager window drag and drop: - lastDir* (filepicker prompt) * If lastDir points to a non-existent directory, defaults to usersDownloadFolder.

pal-moz - I think if you select "Always ask me" in your download options, you should get the behavior you're looking for.

(in reply to comment #9) > pal-moz - I think if you select "Always ask me" in your download options, you > should get the behavior you're looking for. > I know. but I have a same setting for a long time. never select "Always...". I want to select a folder with right-click "Save..." download, but I do not want to select with left-click download. file-picker should open last saved folder, not Desktop. I can do this before check-in for bug 393247, cannot do after check-in. check-in break this behavior.

Peter, I think this summary is actually the reverse of what we're seeing (I'm seeing the same bug, BTW); When I right-click on a file, it first pops up C:\Users\Owner\Downloads, but browser.download.lastDir should actually store that I want to prepopulate a series of quick downloads via right-click, "Save Link As ..." using C:\Users\Owner\Desktop. In that light, shouldn't the summary reflect the fact that browser.download.lastDir seems to get ignored?

Umm, no. open about:config make sure browser.download.useDownloadDir is false check the value of browser.download.lastDir now download by either click on a file or rightclick saveas and choose another directory than what the filepicker comes with. result: browser.download.lastDir gets the new value browser.download.dir isn't changed any download or saveas will show the filepicker start from browser.download.lastDir this is on XP, I don't know if Vista is different.

I filed what I'm seeing in comment 11 as bug 395534. The difference Peter and I were seeing is because of the behavior of true/false as values for browser.useDownloadDir (which shouldn't affect the right-click "Save Link As ..." behavior with regards to browser.download.lastDir's value.

This bug and bug the result of (a decision made in ) Bug 308073, I'm not sure if it should be blocking that one i/o Bug 393247

To be clear, desired behaviour (when browser.download.useDownloadDir = true) is: * clicking on a file saves it to the default download directory (either user set or pulled from system) * clicking on "Save As..." saves it to the last directory used for "Save As..."

Jim, can you comment on the status of this please?

Currently there is only one last dir pref, and it's used anytime the user is asked where to place the file. IMHO that's correct behavior. >In FF2.0.6 both browser.download.dir (default for save) and >browser.download.lastDir (default for saveas) are respected browser.download.dir is not the default for save, it's the default folder when folderList is set to 2 and custom folder is choosen. I would argue this bug should be closed as wont-fix.

WONTFIX, per comment 17

Mike Beltzner, is it moz's opinion to make this invalid adn with that breaking compatibility with F2.0 ?