Closed
Bug 280324
Opened 20 years ago
Closed 19 years ago
browser.download.dir doesn't update to changed Explorer registry value
Categories
(Toolkit :: Downloads API, defect)
Tracking
()
RESOLVED
EXPIRED
People
(Reporter: jbourne, Assigned: bugs)
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 Firefox does not update browser.download.dir location when Windows' default location for the folder (C:\Documents and Settings\[USER]\Desktop) is changed. Firefox continues to download files by default to C:\Documents and Settings\[USER]\Desktop rather than the real Desktop folder that Windows uses. Reproducible: Always Steps to Reproduce: 1. Change the value for Desktop in [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders] from its default to another location. 2. Launch Firefox 3. Download a file using the browser.download.dir (don't save as...) Actual Results: Firefox will download to browser.download.dir, as it is supposed to. However, since browser.download.dir is no longer the same as the value for Desktop in [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders], the download does not appear on the real Windows Desktop folder. Expected Results: Firefox should recognize the registry edit. When the value for Desktop in [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders] is changed and if the value for browser.download.dir is still set to the default C:\Documents and Settings\<USER>\Desktop directory, then Firefox should realize that the real Desktop folder has been changed and update accordingly so that downloads saved to the "default" location show up on the Desktop the user sees rather than in C:\Documents and Settings\<USER>\Desktop. This could easily be argued from two standpoints: as a bug or as a user preference. In my opinion it is a bug, but to others, the status quo may be preferred. From a network administrator's standpoint, it is convenient to change users' Desktop folder to a server that is accessible to all computers. That way, a user can get his own personal Desktop on any workstation where he is logged in to the network. However, it is frustrating to this user that Firefox's downloads do not show up on the Desktop he sees. The user very likely will not know how to edit about:config or Tools > Options... > Downloads > Download Folder to reflect the network location of his Desktop. Even if he does realize the need for the change, it is likely that he either does not know the exact network location of his Desktop folder or doesn't have permission to browse there.
Reporter | ||
Updated•20 years ago
|
Summary: Default download directory doesn't update to changed registry value → browser.download.dir doesn't update to changed Explorer registry value
Reporter | ||
Comment 1•20 years ago
|
||
Just visited your Web site, Ben. Sweet ride. :D
Comment 2•20 years ago
|
||
there's a bug somewhere on using system variables to dictate pref values, until that happens there isn't a lot we can do. If on startup, desktop is set to path X, we'll expand that out and set the pref to a real value. If we didn't do that, it could be useful, but that's non-trivial. This is sort of a dupe, of course. additional note: in the network admin case, I would hope that he sets the paths before the users get the profiles, or how will the find the stuff already saved on their desktops? :)
Comment 3•19 years ago
|
||
This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/
Comment 4•19 years ago
|
||
This bug has been automatically resolved after a period of inactivity (see above comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → EXPIRED
Updated•16 years ago
|
Product: Firefox → Toolkit
You need to log in
before you can comment on or make changes to this bug.
Description
•