Closed Bug 474718 Opened 16 years ago Closed 13 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)

Product:
Toolkit
Component:
Downloads API
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla5

People

(Reporter: hfjimenez, Assigned: Gavin)

References

Details

Attachments

(2 files)

patch
2.95 KB, patch
sdwilsh
: review+
Details | Diff | Splinter Review
Screenshot
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.
Version: unspecified → Trunk
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?
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.
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.
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.
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 7 was meant for another bug - my bad...
(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 → ---
Status: UNCONFIRMED → NEW
Ever confirmed: true
(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.
when will this be fixed ?
Hi! When we can expect fix?
This bug is well over a year old... any timeline on getting a fix?
The same issue applies for the ~/Desktop folder in linux.
Should I file a distinct bug report for this?
Still there on 3.6.6 - that sucks...
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.
This bug is still present in 4.0 b2.
This bug is still present in 4.0 b3

Fix it now! i'm still useing firefox 3.5 because this fking ass issue!
Bug window
20090129021120 - 20090130025441
firefox-3.2a1pre.en-US.win32, file xul.dll
(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
(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.
(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
20090108021547 -> no "Downloads" folder
20090109021526 -> "Downloads" folder is created on desktop
It seems that bug is a side effect of some fix or enhancement
(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.
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...
(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.
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.
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?
Still present in FF 4.0 beta 10.
Still present in FF 4.0 beta 11.
(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.
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.
(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
(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.
(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.
(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)?
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?
that's right. furthermore it's only a line of code as a user already showed some posts above!
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.))
No longer depends on: 429827, 475830
OS: Windows XP → All
Hardware: x86 → All
Attached patch patch — — Splinter Review 
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: nobody → gavin.sharp
Status: NEW → ASSIGNED
(this patch is untested, for the moment)
Comment on attachment 518454 [details] [diff] [review]
patch

r=sdwilsh
Attachment #518454 - Flags: review?(sdwilsh) → review+
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).
Flags: in-testsuite-
http://hg.mozilla.org/mozilla-central/rev/31aab8c246ac
Status: ASSIGNED → RESOLVED
Closed: 16 years ago → 13 years ago
Resolution: --- → FIXED
Whiteboard: fixed-in-cedar
Target Milestone: --- → mozilla2.2
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 → ---
(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: 13 years ago → 13 years ago
Resolution: --- → FIXED
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
Blocks: 649940
No longer depends on: 649940
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".
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.
Oh, I forgot that bug 649940 was filed.
Attached image Screenshot — 
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?
Please update your Firefox to latest stable version (5.0.1) and see if it still happens.
Depends on: 714272
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: