Empty "Downloads" folder should not be created when opening main page of options dialog with a custom download directory set

RESOLVED FIXED in mozilla5

Status

()

Toolkit
Downloads API
RESOLVED FIXED
9 years ago
6 years ago

People

(Reporter: hfjimenez, Assigned: Gavin)

Tracking

(Blocks: 1 bug)

Trunk
mozilla5
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

9 years ago
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.
(Reporter)

Updated

9 years ago
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

Comment 3

9 years ago
see after https://bugzilla.mozilla.org/show_bug.cgi?id=429827#c47

Comment 4

9 years ago
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
Last Resolved: 9 years ago
Depends on: 475830
Resolution: --- → FIXED
Whiteboard: [fixed by bug 475830]
Target Milestone: --- → mozilla1.9.2a1

Comment 6

9 years ago
(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...

Comment 8

9 years ago
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
Duplicate of this bug: 476311
(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

8 years ago
when will this be fixed ?
Duplicate of this bug: 544176
Duplicate of this bug: 552469

Updated

8 years ago
Duplicate of this bug: 541673

Updated

8 years ago
Duplicate of this bug: 561731

Comment 18

8 years ago
Hi! When we can expect fix?
Duplicate of this bug: 563901

Comment 20

8 years ago
This bug is well over a year old... any timeline on getting a fix?

Comment 21

8 years ago
The same issue applies for the ~/Desktop folder in linux.
Should I file a distinct bug report for this?

Comment 22

8 years ago
Still there on 3.6.6 - that sucks...

Comment 23

8 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.
Duplicate of this bug: 582413

Comment 25

8 years ago
This bug is still present in 4.0 b2.

Comment 26

7 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

7 years ago
Bug window
20090129021120 - 20090130025441
firefox-3.2a1pre.en-US.win32, file xul.dll

Comment 28

7 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

7 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

7 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

7 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

7 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

7 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...
(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.
Duplicate of this bug: 591624

Updated

7 years ago
Duplicate of this bug: 594048

Comment 37

7 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.
Duplicate of this bug: 608548

Comment 39

7 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

7 years ago
Still present in FF 4.0 beta 10.

Comment 41

7 years ago
Still present in FF 4.0 beta 11.

Comment 42

7 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

7 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.
(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

7 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.
(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

7 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

7 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

7 years ago
that's right. furthermore it's only a line of code as a user already showed some posts above!

Comment 50

7 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.))
Duplicate of this bug: 639816
No longer depends on: 429827, 475830
OS: Windows XP → All
Hardware: x86 → All
Created attachment 518454 [details] [diff] [review]
patch

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-
Keywords: checkin-needed
http://hg.mozilla.org/projects/cedar/rev/31aab8c246ac
Keywords: checkin-needed
Whiteboard: fixed-in-cedar

Comment 57

7 years ago
http://hg.mozilla.org/mozilla-central/rev/31aab8c246ac
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago7 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
Last Resolved: 7 years ago7 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
Depends on: 649940

Updated

7 years ago
Blocks: 649940
No longer depends on: 649940

Comment 60

7 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".
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.

Comment 63

6 years ago
Created attachment 552000 [details]
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.