Closed Bug 484427 Opened 13 years ago Closed 13 years ago
Download location preference uses the last download directory when disabling "Ask me every time"
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090319 Minefield/3.6a1pre Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090319 Minefield/3.6a1pre If I change the directory I want files to download to in the preferences menu, it changes them, but then resets to the default "Downloads" after closing and reopening Firefox Reproducible: Always Steps to Reproduce: 1. Set download location to Desktop 2. Close Firefox 3. Reopen Firefox 4. Download a file Actual Results: Files download to Downloads, not Desktop Expected Results: should have downloaded to Desktop.
I am seeing this too, but not sure if it is a bug or a profile thing.
Works fine for me on Windows.
Version: unspecified → Trunk
Component: Preferences → Download Manager
Product: Firefox → Toolkit
QA Contact: preferences → download.manager
Status: UNCONFIRMED → NEW
Ever confirmed: true
To get the selected target download folder working, you have to reset the pref browser.download.lastDir. Seems like we always use the folder specified there. I can see the same with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4pre) Gecko/20090312 Shiretoko/3.1b4pre (.NET CLR 3.5.30729) ID:20090312054420
OS: Mac OS X → All
Hardware: Other → All
Shawn: this caused by your recent patch here? Perhaps a lingering pref that we need to reset?
Flags: blocking1.9.1? → blocking1.9.1+
Priority: -- → P2
dao - any reason why you set this as blocking bug 475830? I'm not convinced that that bug caused this issue. A regression window would be really helpful here.
In fact, if I had to guess, I'd say it's this code that would be causing this: http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/downloads/src/nsHelperAppDlg.js.in#251 Bug 464795 looks suspicious to me...
(In reply to comment #5) > dao - any reason why you set this as blocking bug 475830? Because this kind of breaks that feature. But I guess if bug 475830 hadn't happened, we'd see the same issue, just with the desktop instead of the download folder? > Bug 464795 looks suspicious to me... That hasn't landed on branch, and comment 3 seems to indicate that this is broken on branch. I can't say if that is correct, as I'm usually on trunk and I don't know how to reproduce this bug. I haven't used private browsing yet, if that matters.
(In reply to comment #7) > Because this kind of breaks that feature. But I guess if bug 475830 hadn't > happened, we'd see the same issue, just with the desktop instead of the > download folder? OK - that's what people tend to do when marking regressions, and you removed the qawanted when you set that, so I thought you were saying this was a regressions from that bug.
No, I actually added qawanted at the same time ;)
Whimboo: regression range?
I'm confirming something funky is going on here. My pref is magically changing between a value I set it to and the default location. Investigating.
Whiteboard: [needs investigation]
Actually, I can't seem to reproduce what I saw in comment 11 - may have started the wrong profile, and I can't reproduce comment 0 either. This is in Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090324 Minefield/3.6a1pre Can someone get me reliable steps to reproduce here?
Whiteboard: [needs steps to reproduce]
Set your download location to something other than downloads, then close the browser. It may need to be started a few times, maybe even takes a few hours to get to switch.
(In reply to comment #13) > Set your download location to something other than downloads, then close the > browser. It may need to be started a few times, maybe even takes a few hours to > get to switch. So, that's steps to reproduce, yes, but it's missing the important part of what I asked for, which is reliable. We have two WFM, and three people able to reproduce it, so there must be something in common with the three that are able to reproduce it. I am not buying the argument that this is somehow time dependent.
It has never occurred to me, although the location has been changed to Desktop from the beginning, and I open and close the browser about 4 or 5 times a day. I never used safebrowsing, never "Always ask me where to safe files" and I also rarely use "Safe As" (points mostly to desktop). I have no download extensions installed. With the exception of "Video Download" which started to malfunction shortly ago and which I uninstalled.
Sorry, but I haven't got any bug mail because I forgot to cc myself. I'll check which information I can get here. I'll respond asap.
The steps to reproduce this bug are easy. Follow these ones: 1. Create a fresh profile 2. Change the download setting to "ask me each time" 3. Save on file to the local disk 4. Change download setting back to "Save files to" and specify desktop as target folder 5. Try to save the same file again With step 5 you will end up in the folder from step 3 instead of seeing the desktop folder. It would be great if someone else can check for a regression range because I have to finish the FFT's. XtC4YaLL, would you have time?
OK, comment 17 indicates a different kind of bug from comment 0. Consequently, I'm not sure this is a blocker anymore (it's quite possible we did this in 3.0 actually), so I'm renominating this and updating the title.
Flags: blocking1.9.1+ → blocking1.9.1?
Summary: Download location preference resets after closing Firefox. → Download location preference uses the last download directory when disabling "Ask me every time"
I haven't touched the "Always ask me" pref.
This happens for me with the "Download to location", not with ask everytime.
I can't reproduce the steps of comment 17, at least not the result. As soon as I set "Desktop" the download goes to desktop. Very obedient browser here. So the question is: are comment 0, comment 19 and comment 20 tested with a new profile and if not, what setting or extension or peculiar other factor do they have in common?
Always a fresh profile and no add-ons installed. I think comment 0 refers to an existing profile and has probably switched back to the "Save files to" option. If yes, the restart should not be necessary because the new pref settings are active immediately. Personally I can get it to work with resetting the lastDir pref.
Henrik, still wonder why it would be necessary to reset the pref in about:config, because the options in the Options window are working perfectly here. I tested it repeatedly with a new profile in two different ways and couldn't reproduce the problem. So there are two cases here now: Henrik's "fixed" browser.download.lastDir preference (why can't this be reproduced by everyone) and the other case (reproduced by at least 2 other persons but possibly 4) of "Save files to".
The options window doesn't reset the lastDir pref. So one possible trace could be the following: promptForSaveToFile is called to not force a prompt. That's why we don't obey the autodownload pref and jump down to file picker code which only checks the lastDir pref. If it's present it will use this folder. Otherwise the userDownloadsDirectory is used. At least that would explain the steps I have to do to get it working.
Agree with sdwilsh, the steps seem more esoteric and not something we should block on.
(In reply to comment #17) > The steps to reproduce this bug are easy. Follow these ones: > 1. Create a fresh profile > 2. Change the download setting to "ask me each time" > 3. Save on file to the local disk > 4. Change download setting back to "Save files to" and specify desktop as > target folder > 5. Try to save the same file again > With step 5 you will end up in the folder from step 3 instead of seeing the > desktop folder. > It would be great if someone else can check for a regression range because I > have to finish the FFT's. XtC4YaLL, would you have time? On step #3, and step #5, how are you saving? If you're saving via something that defaults to lastDir (like saving an image out of a page using the context menu "save image as") you're seeing correct behavior. If on the other hand you're clicking on a link to something like a zip file (and bringing up the unknown content dialog) and seeing this it may be a bug. I just tested and can't reproduce using a link to a zip. My steps: 1) fresh profile 2) Change the download setting to "ask me each time". On Vista the default download location remains the Downloads folder 3) Click on a zip link The content dialog opens with the default on "Open (with explorer)". I change that to the "Save File" option and press ok. The file browser opens to Downloads and I hit save. 4) Change download setting back to "Save files to" and specify desktop as target folder 5) Click on a zip link again The content dialog opens with the default on "Save File" and I press ok. Result: The zip file is saved to the Desktop. I'm tempted to mark this is invalid in that I think things are working correctly. Related bug: Bug 395534 - browser.download.lastDir is ignored when right-clicking and "Save Link As ..."
Jim, you are right. I wasn't aware of bug 395534. With the clear statement of UX this bug is invalid. For my tests I really used the context menu so a file picker with the last download location was always shown. Downloading a file directly it works as expected. Thanks for the hint.
You need to log in before you can comment on or make changes to this bug.