Closed
Bug 474718
Opened 16 years ago
Closed 14 years ago
Empty "Downloads" folder should not be created when opening main page of options dialog with a custom download directory set
Categories
(Toolkit :: Downloads API, defect)
Toolkit
Downloads API
Tracking
()
RESOLVED
FIXED
mozilla5
People
(Reporter: hfjimenez, Assigned: Gavin)
References
Details
Attachments
(2 files)
2.95 KB,
patch
|
sdwilsh
:
review+
|
Details | Diff | Splinter Review |
29.03 KB,
image/png
|
Details |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090121 Minefield/3.2a1pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090121 Minefield/3.2a1pre
Only happens when selecting the Main tab in the Options dialog. Mi default download directory is in another drive. (Not system drive)
Reproducible: Always
Steps to Reproduce:
1. "Tools/Options" menu
2. "Main" Tab
3. If you didn't have a "Downloads" folder en your desktop, now you do.
Expected Results:
Nothing, I already have a folder to download files into.
Comment 1•16 years ago
|
||
Confirmed on Windows XP. Regression range: http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2009-01-08+00%3A00%3A00&enddate=2009-01-09+08%3A00%3A00
When I search for the word download I find Bug 429827. This seems intentional?
Comment 2•16 years ago
|
||
In any case this explains the mystery of finding Download folders while configuring two new computers. It made me puzzled and I had no idea that it was Firefox doing this :-)
Inconsequently it doesn't download new files automatically to this Downloads folder.
Updated•16 years ago
|
Component: Preferences → Download Manager
Depends on: 429827
Product: Firefox → Toolkit
QA Contact: preferences → download.manager
by bug 475830 ,
[STR]
open Tools>Options >>> Main
"Downloads" folder is created in "My Documents" folder, even if set "Desktop".
this is not necessary.
Comment 5•16 years ago
|
||
This has been fixed by bug 475830 on trunk. Still waiting for 1.9.1 approval.
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Depends on: 475830
Resolution: --- → FIXED
Whiteboard: [fixed by bug 475830]
Target Milestone: --- → mozilla1.9.2a1
(In reply to comment #5)
> This has been fixed by bug 475830 on trunk. Still waiting for 1.9.1 approval.
why fixed ?
I think the folder should not be created on desktop or in MyDocuments, if download is set to "Desktop" or other folder.
Comment 7•16 years ago
|
||
This bug doesn't do anything about creating a folder, so I'm not sure why you are commenting here...
bug title says ""Creates an empty "Downloads" folder"".
if
> I think the folder should not be created on desktop or in MyDocuments, if
> download is set to "Desktop" or other folder.
is another bug, I'll file a new bug.
Comment 10•16 years ago
|
||
(In reply to comment #6)
> why fixed ?
>
> I think the folder should not be created on desktop or in MyDocuments, if
> download is set to "Desktop" or other folder.
Sorry, my bad. That's true. Reopening this bug.
Shawn, will this be fixed by the patch on bug 429827?
Status: RESOLVED → UNCONFIRMED
Resolution: FIXED → ---
Summary: Creates an empty "Downloads" folder on desktop when opening Tool/Options... → Empty "Downloads" folder should not be created when opening main page of options dialog
Whiteboard: [fixed by bug 475830]
Target Milestone: mozilla1.9.2a1 → ---
Updated•16 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 12•16 years ago
|
||
(In reply to comment #10)
> Shawn, will this be fixed by the patch on bug 429827?
I don't know. I haven't had a chance to build and debug this on windows.
Comment 13•15 years ago
|
||
when will this be fixed ?
Comment 18•15 years ago
|
||
Hi! When we can expect fix?
Comment 20•15 years ago
|
||
This bug is well over a year old... any timeline on getting a fix?
Comment 21•15 years ago
|
||
The same issue applies for the ~/Desktop folder in linux.
Should I file a distinct bug report for this?
Comment 22•15 years ago
|
||
Still there on 3.6.6 - that sucks...
Comment 23•15 years ago
|
||
I confirm the presence of this bug in the last Firefox 4.0 beta 1.
It seems that the old code which is responsible for this has not been rewritten and checked for a long time... See also the support forum:
http://support.mozilla.com/tiki-view_forum_thread.php?locale=en&comments_parentId=586823&forumId=1
I traced a source code: browser.jar\content\browser\preferences\main.js with debugger (Firefox 3.6.6, Windows XP)
...
/**
264 * Initializes the download folder display settings based on the user's
265 * preferences.
266 */
267 displayDownloadDirPref: function ()
268 {
- 269 var folderListPref = document.getElementById("browser.download.folderList");
- 270 var bundlePreferences = document.getElementById("bundlePreferences");
- 271 var downloadFolder = document.getElementById("downloadFolder");
- 272 var currentDirPref = document.getElementById("browser.download.dir");
273
274 // The user's download folder is based on the preferences listed above.
275 // However, if the system does not support a download folder, the
276 // actual path returned will be the system's desktop or home folder.
277 // If this is the case, skip off displaying the Download label and
278 // display Desktop, even though folderList might be 1.
279 var fileLocator = Components.classes["@mozilla.org/file/directory_service;1"]
- 280 .getService(Components.interfaces.nsIProperties);
- 281 var desk = fileLocator.get("Desk", Components.interfaces.nsILocalFile);
- 282 var dnldMgr = Components.classes["@mozilla.org/download-manager;1"]
- 283 .getService(Components.interfaces.nsIDownloadManager);
>> 284 var supportDownloadLabel = !dnldMgr.defaultDownloadsDirectory.equals(desk);
285
286 // Used in defining the correct path to the folder icon.
- 287 var ios = Components.classes["@mozilla.org/network/io-service;1"]
- 288 .getService(Components.interfaces.nsIIOService);
- 289 var fph = ios.getProtocolHandler("file")
- 290 .QueryInterface(Components.interfaces.nsIFileProtocolHandler);
- 291 var iconUrlSpec;
...
Line 284 is responsible for this bug, the folder "Downloads" is created exactly after this code has been executed. Unfortunately I cannot trace deeper just now and I'm not a professional JS developer. However, I hope this can help.
Comment 25•15 years ago
|
||
This bug is still present in 4.0 b2.
Comment 26•15 years ago
|
||
This bug is still present in 4.0 b3
Fix it now! i'm still useing firefox 3.5 because this fking ass issue!
Comment 27•14 years ago
|
||
Bug window
20090129021120 - 20090130025441
firefox-3.2a1pre.en-US.win32, file xul.dll
Comment 28•14 years ago
|
||
(In reply to comment #27)
> Bug window
> 20090129021120 - 20090130025441
> firefox-3.2a1pre.en-US.win32, file xul.dll
wrong.
see "Description"
this bug was reported on 2009-01-21.
and see com#1
range is 20090108-20090109 Nightly.
maybe http://hg.mozilla.org/mozilla-central/rev/cab8b946ee86
Comment 29•14 years ago
|
||
(In reply to comment #28)
> (In reply to comment #27)
> > Bug window
> > 20090129021120 - 20090130025441
> > firefox-3.2a1pre.en-US.win32, file xul.dll
>
> wrong.
> see "Description"
> this bug was reported on 2009-01-21.
>
> and see com#1
> range is 20090108-20090109 Nightly.
> maybe http://hg.mozilla.org/mozilla-central/rev/cab8b946ee86
You are right, more exactly:
20090129021120 -> "Downloads" folder is created on desktop
20090130025441 -> "Downloads" folder is created in My Documents
I will look in earlier builds.
Comment 30•14 years ago
|
||
(In reply to comment #29)
> You are right, more exactly:
> 20090129021120 -> "Downloads" folder is created on desktop
> 20090130025441 -> "Downloads" folder is created in My Documents
see com#4
Comment 31•14 years ago
|
||
20090108021547 -> no "Downloads" folder
20090109021526 -> "Downloads" folder is created on desktop
It seems that bug is a side effect of some fix or enhancement
Comment 32•14 years ago
|
||
(In reply to comment #31)
> It seems that bug is a side effect of some fix or enhancement
yes, https://bugzilla.mozilla.org/show_bug.cgi?id=429827#c37
check/read related bugs.
Comment 33•14 years ago
|
||
Yes, I have read the discussion there and a code, eventually it's clear when and why the idea do make a "Downloads" directory came to life, initially to desktop, later to My Documents - as I have found out by checking the nightly builds. I also understand that it's more a design issue rather than a bug:
// This could be the first time we are creating the downloads folder on the
// desktop, so make sure it exists.
This explains a lot. Instead of checking first, whether the user had specified the download directory in options and that directory is accessible and is able to store files, developers decided instead create a "bullet-proof" directory which would be accessible any moment. Now, to fix this bug (or issue), need to convince people, who implemented it, change their mind. Will it be easy?
- We create the "Downloads" folder to be sure that you will be able to save downloads any time, for the sake of browser stability.
- But I don't need this default folder, let me choose my own folder for downloads! (see the support forum)
- We are developers, we understand more...
Comment 34•14 years ago
|
||
(In reply to comment #33)
> - We create the "Downloads" folder to be sure that you will be able to save
> downloads any time, for the sake of browser stability.
> - But I don't need this default folder, let me choose my own folder for
> downloads! (see the support forum)
> - We are developers, we understand more...
None of these. It's a complicated problem, and there are more important things to fix. Patches are gladly accepted if this is seriously bothering you.
Comment 37•14 years ago
|
||
I would just like to say this to all developers - the My Documents folder is MY folder, not yours. It irritates the hell out of me all the programs that think they have the obligation to create a folder in My Documents for their program. Just don't do it! It's not your My Documents folder! Thanks.
Comment 39•14 years ago
|
||
This issue is still present in FF 4.0 beta 7. I know the devs have lots of other stuff to work on, but it's been well over a year, and the exact line of code that causes the problem has been isolated. Could we get a fix for this?
Comment 40•14 years ago
|
||
Still present in FF 4.0 beta 10.
Comment 41•14 years ago
|
||
Still present in FF 4.0 beta 11.
Comment 42•14 years ago
|
||
(In reply to comment #41)
> Still present in FF 4.0 beta 11.
we know, because this bug is not fixed.
so please stop spamming.
Comment 43•14 years ago
|
||
Firefox 'spams' my My Documents folder multiple times a day. I honestly don't think *one* report per major beta release that *still* contains this extremely annoying issue (whose cause has already been localized) constitutes spam.
Comment 44•14 years ago
|
||
(In reply to comment #43)
> Firefox 'spams' my My Documents folder multiple times a day. I honestly don't
> think *one* report per major beta release that *still* contains this extremely
> annoying issue (whose cause has already been localized) constitutes spam.
It certainly violates https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
Comment 45•14 years ago
|
||
(In reply to comment #44)
> (In reply to comment #43)
> > Firefox 'spams' my My Documents folder multiple times a day. I honestly don't
> > think *one* report per major beta release that *still* contains this extremely
> > annoying issue (whose cause has already been localized) constitutes spam.
> It certainly violates https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
How?
Under rule #1, which I assume is the one you're referring to, I cite the following excerpt:
"Additional "I see this too" or "It works for me" comments are unnecessary unless they are on ... a significantly different build."
Major beta releases are significantly different enough from each other to warrant an update.
Comment 46•14 years ago
|
||
(In reply to comment #45)
> Major beta releases are significantly different enough from each other to
> warrant an update.
It's not considered significant. Significant would be Firefox 3.6 -> 4.0, or 4.0 -> 5.0. Different betas for the same release are not substantially different.
Additionally, a bug that is triage and confirmed needs these type of comments even less. Yes, this bug exists, but it has not been a high priority to fix it.
Comment 47•14 years ago
|
||
(In reply to comment #46)
> It's not considered significant.
That's debatable, but if that's truly the case, the rules should be updated to reflect what constitutes "significant". Rules which are open to interpretation are not well-written rules.
So are we to assume that the developers have no intention of looking into this paper cut before Firefox 4.1 (or whatever comes after 4.0)?
Comment 48•14 years ago
|
||
Firefox is falling behind. The Google Chrome user-base is rapidly growing supposedly because "Chrome has fixed problems and made improvements to the browser experience many of us didn't recognize until Chrome fixed them."
Most FF users probably wouldn't recognize this issue as a problem. Savvy users see it every day. This bug has been a constant irritant for a number of major FF releases. It should be addressed.
If not now, when?
Comment 49•14 years ago
|
||
that's right. furthermore it's only a line of code as a user already showed some posts above!
Comment 50•14 years ago
|
||
Still present in FF 4.0 beta 12. (The powers that be may update the rules if reports like this are unwarranted; given the current rules, my interpretation is that the difference between the major beta releases is significant. (And that's a complement to the work that's been done on beta 12, BTW.))
Assignee | ||
Updated•14 years ago
|
Assignee | ||
Comment 52•14 years ago
|
||
This doesn't solve the root problem - the defaultDownloadsDirectory getter will still create the directory if it doesn't exist. Changing that is probably risky, though, since consumers likely depend on it returning an existing folder.
Instead this mitigates the problem by avoiding the call to that getter when the pref pane is initialized. We'll still call the getter after picking a new download directory (since we need to compare it to the default and desktop to know whether to show the relevant simple labels in the Download location box), but that occurs much less frequently.
The code that was calling this on initialization was trying to handle the case where the default download directory actually turned out to be the Desktop, so that we could show the "Desktop" label rather than the "Downloads" label. Based on the nsDownloadManager/directory service code, though, the defaultDownloadsDirectory getter can only return the desktop on OS X 10.4, which we no longer support, so I'm just ripping out this code.
Attachment #518454 -
Flags: review?(sdwilsh)
Assignee | ||
Updated•14 years ago
|
Assignee: nobody → gavin.sharp
Status: NEW → ASSIGNED
Assignee | ||
Comment 53•14 years ago
|
||
(this patch is untested, for the moment)
Comment 54•14 years ago
|
||
Comment on attachment 518454 [details] [diff] [review]
patch
r=sdwilsh
Attachment #518454 -
Flags: review?(sdwilsh) → review+
Assignee | ||
Comment 55•14 years ago
|
||
I tested that this fixes the issue in the common case (Downloads folder is customized to some non-default location, and the General pane is opened).
Assignee | ||
Updated•14 years ago
|
Flags: in-testsuite-
Assignee | ||
Updated•14 years ago
|
Keywords: checkin-needed
Comment 56•14 years ago
|
||
Keywords: checkin-needed
Whiteboard: fixed-in-cedar
Comment 57•14 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 16 years ago → 14 years ago
Resolution: --- → FIXED
Whiteboard: fixed-in-cedar
Target Milestone: --- → mozilla2.2
Comment 58•14 years ago
|
||
Still not fixed. Opening the preferences dialog with a clean profile immediately creates the downloads folder, and not after selecting another folder. Tested with Mozilla/5.0 (Windows NT 5.1; rv:2.2a1pre) Gecko/20110330 Firefox/4.2a1pre
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 59•14 years ago
|
||
(In reply to comment #58)
> Still not fixed. Opening the preferences dialog with a clean profile
> immediately creates the downloads folder, and not after selecting another
> folder.
That's known, see comment 55. This only fixes the case where a custom download directory is specified. Fixing all cases is much trickier. You can file a followup if desired.
Status: REOPENED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → FIXED
Assignee | ||
Updated•14 years ago
|
Summary: Empty "Downloads" folder should not be created when opening main page of options dialog → Empty "Downloads" folder should not be created when opening main page of options dialog with a custom download directory set
Updated•14 years ago
|
Comment 60•14 years ago
|
||
I'm commenting here because Bug 639816 is marked as a duplicate of this bug. I think that's incorrect, but choose to follow admins' decision for now. This bug seems to be subject to a judgment call on proper program behavior, triggered by the Options dialog and largely related to the first run of Firefox on a given profile. By contrast the behavior I've observed, per 639816, is simply incorrect, triggered by the downloads window and an ongoing nuisance until the user eventually gets fed up enough to implement a silly little workaround.
If FF 4.0.1 Win32 has ever been set to "Save files to" a location, then changed to "Always ask me where to save files", it will properly save each file to the location the user selects but also silently recreate the "Save files to" directory with nothing inside it every time the downloads window appears. The workaround is to temporarily switch the browser back to "Save files to", change the location to some place that will always exist, then switch back to "Always ask me".
Assignee | ||
Comment 61•14 years ago
|
||
I don't think there's any disagreement about what the behavior _should_ be. The problem is that changing the behavior involves either a) potentially breaking expectations of third party code using this interface or b) a hacky, complicated workaround. Neither of those are impossible options, but there was a much simpler approach that solved the problem for a significant portion of users, so I took that approach here. We can investigate more thorough fixes in a followup bug, if someone wants to file one.
Assignee | ||
Comment 62•14 years ago
|
||
Oh, I forgot that bug 649940 was filed.
Comment 63•14 years ago
|
||
I am running Firefox v3.6.19 (Mozilla/5.0; rv:1.9.2.19; Gecko/20110707) on Windows XP. I have selected a non-default but persistent "Save files to" folder, and checked the "Always ask me where to save files" option. See attached screenshot.
Every time when I navigate to the General section in Tools -> Options, however, a "Downloads" folder is still automatically created in "My Documents" folder. Is this expected?
Comment 64•14 years ago
|
||
Please update your Firefox to latest stable version (5.0.1) and see if it still happens.
You need to log in
before you can comment on or make changes to this bug.
Description
•