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)

x86
Windows XP
defect
Not set
minor

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.
Summary: Default download directory doesn't update to changed registry value → browser.download.dir doesn't update to changed Explorer registry value
Just visited your Web site, Ben. Sweet ride. :D
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? :)
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/
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
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.