Closed Bug 384068 Opened 17 years ago Closed 15 years ago

[10.5] Firefox should download files to Leopard's Download Stack by default

Categories

(Toolkit :: Downloads API, defect, P2)

All
macOS
defect

Tracking

()

VERIFIED FIXED
mozilla1.9.2a1

People

(Reporter: kroc2000, Assigned: sdwilsh)

References

()

Details

(Keywords: verified1.9.1, Whiteboard: [polish-easy][polish-p2])

Attachments

(1 file, 3 obsolete files)

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-GB; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-GB; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3

Now that the Leopard Beta is in developer's hands, and that Leopard provides a system recognised location for downloads, Firefox should use this location by default.

Reproducible: Didn't try

Steps to Reproduce:
1. Get Leopard Beta
2. Download a File...
Actual Results:  
File downloads to the desktop by default

Expected Results:  
File should download to the system provided Downloads folder/stack

I don't have Leopard personally, just throwing this up here as I thought of it right away.
We'll need to set the pref to use the Download Stack by default for Leopard but keep the standard download directory for other versions of the OS. 
Assignee: nobody → joshmoz
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking-firefox3?
Version: unspecified → Trunk
Josh, do you plan on working on this?
Yes
Thunderbird equivalent: bug 385438 
Hello Shawn ...
you said in bug 385438
"Actually, the back-end for this (where it will need to be fixed) is in toolkit,
so fixing it for one fixes it for all."

Ok, so, if the bug for TB is dup of this one, maybe, for visibility and avoid a 3rd bug for SeaMonly, we need to change Product from Firefox to Toolkit ... or, if we let Firefox here, reopen bug 385438 and set that bug 384068 blocks bug 385438.

no?
There is no Toolkit->Download Manager.  Sadly, we just get to dupe bugs here.
Josh, would it make sense (if the risk is low) to port the fix we come up with for this to the branch in order to maximize our compatibility with leopard? If so we can nominate this bug for wanted1.8.1.x
Yes, we should probably port to the branch.
nominating for wanted1.8.1.x. This is something we'll want to port for Leopard compatibility when we have a fix.
Flags: wanted1.8.1.x?
Flags: blocking-firefox3? → blocking-firefox3+
Target Milestone: --- → Firefox 3 M9
Summary: Firefox should download files to Leopard's Download Stack by default → [10.5] Firefox should download files to Leopard's Download Stack by default
This actually Just Worked with a new profile for me. I think we grab the default downloads location out of the OS, which returns Downloads on Leopard.

It doesn't do the fancy bounce that happens when a download finishes with Safari, but I think that's a separate bug.
I think Jim ended up fixing it when he fixed it for Vista.  Colin - if you want to resolve this, that'd be great.
I'm 99% sure it just worked. If someone on Leopard finds this doesn't work, feel free to re-open.

Also I'd be curious to see what happens if you import a profile from Tiger.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
Ok, i confirm this, Firefox 2.0.0.6 is downloading to download stack on Leopard build 9A500n (fresh profile)

But i'm 100% sure that it was not working with 2.0.0.3 (download to desktop).

So, i agree with Shawn Wilsher at comment 12

PS: This should be RESOLVED FIXED and not RESOLVED WORKSFORME, as it was fixed.

PS2: The bug equivalent 385438 i've filled for Thunderbird is a dup of this one ... I cannot test TB on Leopard now ... but this should be tested with TB before closing the bug ...
Resolution: WORKSFORME → FIXED
Unless we have a bug # that this was fixed by or there's a patch in this bug that fixed it, it's WORKSFORME
Resolution: FIXED → WORKSFORME
Err... really?

Colin are you sure you see this behavior? I just tried it with a new user account, which, thus, had a new profile, and it defaulted to the Desktop. I'm also using 9A500n, which is no longer the latest seed.

I'm reopening this until someone can confirm that the behavior is actually different when using a new profile and the latest version of both 10.5 and Minefield.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
i was using 2.0.0.6, not minefield ... maybe the trunk has a different behavior? 
What was the version of the minefield you tried?
No, I'm not 100% sure. If you're definitely not seeing it, then I must have just been imagining things.

We should also figure out how to get it to do the bouncing thing on a completed download. Hopefully there's a public method to do that (but I'm not overly optimistic).
Litmus Triage Team: marcia will handle this test case.
Target Milestone: Firefox 3 M9 → Firefox 3 M10
There is a lot of confusing testimony as to whether or not this is still a bug on trunk and branch.

In my testing with a fresh profile, both Firefox 2 and 3 default to downloading to the desktop, so this is still a bug on trunk and the 1.8 branch.

Anyone still disagree with that?
I just installed Leopard and then immediately installed Firefox 2.0.0.7 and it's defaulting to the Desktop for downloads.
Attached patch fix v1.0 (obsolete) — Splinter Review
This whole system for handling the default download location is really, really poorly done. This patch seems like the best way to fix the problem without getting too intrusive.

The one thing we might want to change is adding a localization entry for "Downloads". I can do that if we're allowed to add localization entries on the 1.8 branch, but I don't think we can.
Attachment #285967 - Flags: review?(mano)
Comment on attachment 285967 [details] [diff] [review]
fix v1.0

Actually, this messes up 10.4. New patch coming up.
Attachment #285967 - Attachment is obsolete: true
Attachment #285967 - Flags: review?(mano)
Attached patch fix v1.1 (obsolete) — Splinter Review
This is a better way to do things. Works perfectly for me on 10.4 and 10.5.
Attachment #286024 - Flags: review?(mano)
Josh,
To clarify, is this patch just for 1.8.1 or is this for trunk?

Trunk code should be using nsIDownloadManager::GetDefaultDownloadsDirectory (http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/toolkit/components/downloads/src/nsDownloadManager.cpp&rev=1.138#875) and/or nsIDownloadManager::GetUserDownloadsDirectory (http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/toolkit/components/downloads/src/nsDownloadManager.cpp&rev=1.138#954)
This patch is for Firefox 2, the 1.8.1 branch. I have made no attempt to fix this on the trunk yet.
On trunk, this is tied into the user's prefs settings. 

For downloaded files, download manager's new userDownloadsDirectory attrib is
used when the download directory pref (browser.download.folderList) indicates
use the user's default download folder. 

With this set, on 10.4, system directory service returns a download folder
(configured by safari I believe) or if that isn't setup, the desktop. As a
result, on 10.4 the resulting download folder is either the safari download
folder, or Desktop/Downloads.

If 10.5 has a new user default download directory, we just need to make sure
that path is being returned by directory service. Everything else should be in
good shape.

Also, I should note it's important to pay attention to
browser.download.folderList when testing. A value of 0 indicates the Desktop, 1
indicated the user's download directory, and 2 indicates a custom path.
>This whole system for handling the default download location is really, really
>poorly done.

The patch on trunk for bug 308073 was an attempt to clean all this up. It kicked off quite a discussion, but that's all stablized now and I think things are in good shape going forward. main.js has some nice comments explaining the behavior as it relates to prefs.
Attached patch trunk fix v1.0 (obsolete) — Splinter Review
Attachment #286082 - Flags: review?(edilee)
Comment on attachment 286082 [details] [diff] [review]
trunk fix v1.0

(I can't actually give r+'s)

For nsDownloadManager::GetDefaultDownloadsDirectory, should we update the comment to be the download stack? But technically it /is/ Safari's download folder?

  // OSX:
  // Safari download folder or Desktop/Downloads

For pre-10.5, setting the pref seems to create a "Downloads" folder on the desktop. Do we want that to be the default?
Attachment #286082 - Flags: review?(comrade693+bmo)
Comment on attachment 286082 [details] [diff] [review]
trunk fix v1.0

This trunk fix doesn't work correctly, I don't know much about this code. I'm going to follow through on my branch fix because that is a priority right now, but leave the trunk fix up to the Firefox team.
Attachment #286082 - Attachment is obsolete: true
Attachment #286082 - Flags: review?(edilee)
Attachment #286082 - Flags: review?(comrade693+bmo)
nsExternalHelperAppService.cpp should probably be updated as well for "Open With..." downloads.
I'm getting the following error message when I save a file in firefox 2.0.0.8 - I had set the download preference to my homedir/Downloads directory so it would use the stack which started the problem, but now I changed it to "Ask me everytime" and still get this error:

Downloading /Developer/SDKs/MacOSX10.5.sdk/usr/X11/include/X11/Xaw/TreeP.h/peeerf3qj.csv

/Developer/SDKs/MacOSX10.5.sdk/usr/X11/include/X11/Xaw/TreeP.h/peeerf3qj.csv could not be saved, because an unknown error occurred.

Try saving to a different location.
>If 10.5 has a new user default download directory, we just need to make sure
>that path is being returned by directory service. Everything else should be in
>good shape.

I should also mention, if like with Vista we want different settings for the folderList pref depending on the version of the os, there's a little chunk of code in /browser/base/content/browser.js for the patch to 308073 that detects Vista and sets folderList to 1 on new profiles. The same logic would probably work for osx.
Comment on attachment 286024 [details] [diff] [review]
fix v1.1

Jim, can you take a look at this please - you know the code best.  Gavin says he'll take a look once you OK it.

Talking to UX now about what we want to do with different versions of the OS.
Attachment #286024 - Flags: review?(mano) → review?(jmathies)
For clarity:
sdwilsh: so, it goes to the desktop still on 10.4, but goes to the stack on 10.5?
josh: yes
>if (customDirPref.value) { 
>  downloadFolder.label = this._getDisplayNameOfFile(customDirPref.value); 
>} 

This is incorrect, because customDirPref points to browser.download.dir, which
may be populated but may not apply. The value you want to look at first is
folderListPref, which indicates whether or not customDirPref applies.

folderList = 0 : desktop
folderList = 1 : dirService.get("DfltDwnld", Components.interfaces.nsIFile)
folderList = 2 : customDirPref 

Note that dirService.get("DfltDwnld", Components.interfaces.nsIFile) may return
the download folder, or the desktop -

http://lxr.mozilla.org/mozilla/source/xpcom/io/nsDirectoryService.cpp#899

Overall, I'm not following the logic - we're introducing a new label here, when we should already have support for it. (It's "My Downloads" in branch, not
"Downloads" though.) I don't have osx to test on but I believe it should show up in prefs if you set folderList to 1.

Instead, maybe just update that string for osx (if we can do that for updates?), and stick with the existing folderList functionality, which should
be working without these changes. Then add a switch on boot such that if
folderList == 0 and osx == 10.5 and newprofile then folderList = 1.
Also, just noticed, we've updated the default save as folder in nsHelperAppDlg.js for all versions of osx. So users on 10.4 which used to go to user docs will now be going to either safari's downloads folder or the desktop once they update.

The more I look at this the more it feels like it's more appropriate for a major update rather than a minor one. We made the opposite decision on Vista, so I'm curious if we really want to be pushing something like this through right now.
I am unsure if this is the same bug, but a reader on my blog pointed out that after choosing the Downloads folder as the default download place, while *downloading* drops the file in the right place, choosing "open with" an application (say Preview.app for PDF files) will still download the file onto the Desktop (and open it from there). I can confirm this for Minefield.
(In reply to comment #39)
> I am unsure if this is the same bug, but a reader on my blog pointed out that
> after choosing the Downloads folder as the default download place, while
> *downloading* drops the file in the right place, choosing "open with" an
> application (say Preview.app for PDF files) will still download the file onto
> the Desktop (and open it from there). I can confirm this for Minefield.
That's what my Comment 32 is about.
Blocks: 402520
Flags: blocking1.8.1.10?
(In reply to comment #39)
> I am unsure if this is the same bug, but a reader on my blog pointed out that
> after choosing the Downloads folder as the default download place, while
> *downloading* drops the file in the right place, choosing "open with" an
> application (say Preview.app for PDF files) will still download the file onto
> the Desktop (and open it from there). I can confirm this for Minefield.

That doesn't happen even without my patch in my testing. The external helper app stuff just goes straight for the default system download directory, which is determined by the OS IC service. It has nothing to do with the browser prefs, and correctly points to the downloads dir on 10.5.
Attachment #286024 - Flags: review?(jmathies) → review-
I have a new patch coming up that does things in a better way.
Moving blocking nomination back after rename, but is this fix really appropriate for a 2.0.0.x release? Especially given code-freeze in about a week?
Flags: blocking1.8.1.11? → blocking1.8.1.10?
Target Milestone: Firefox 3 M10 → Firefox 3 M11
I don't know if it is appropriate, if I'm told it isn't I'll stop working on it. I don't know the history of these kinds of fixes on branches very well.
Priority: -- → P4
Flags: blocking1.8.1.10? → blocking1.8.1.11?
Hardware: Macintosh → All
... in writing as an enduser in 'bugzilla' I hope not to trespass a threshold ...
But what you are discussing here is a boring feature of Firefox 2.0.0.x under OS X.5.
Please take the appropriate steps to resolve this problem in the near future.
As you know MAC-users are constrained to use Flip4Mac to properly stream p.e. wmv-files. And this regularly leads to the abovementioned effect: wmv-files are clutterin the desktop...
Thank you.
Very much wanted, but if this doesn't happen for some reason it will not block the release.
Status: REOPENED → ASSIGNED
Flags: wanted-firefox3+
Flags: blocking-firefox3-
Flags: blocking-firefox3+
AIUI the current behavior is that it ignores any preference you set for download location, even if you set it in Firefox. If this is the case, this should block the release.
If it's not even blocking for trunk it's not going to block a security release.
Flags: blocking1.8.1.12? → blocking1.8.1.12-
Just to file it: Firefox 3.0 Beta 3 on OS X 10.5 also ignores the download folder for files sent to helper apps. Example: I have configured my Firefox to open M3U-Files with VLC. I also have my Firefox configured to download all files to the Leopard download folder. But all M3U files that Firefox downloads and sends to VLC are stored on the desktop. I would expect a behaviour as on Windows, where those temporary files are stored in the temp folder.
(In reply to comment #49)
> Just to file it: Firefox 3.0 Beta 3 on OS X 10.5 also ignores the download
> folder for files sent to helper apps. Example: I have configured my Firefox to
> open M3U-Files with VLC. I also have my Firefox configured to download all
> files to the Leopard download folder. But all M3U files that Firefox downloads
> and sends to VLC are stored on the desktop. I would expect a behaviour as on
> Windows, where those temporary files are stored in the temp folder.
> 

I forgot to say that Safari is also configured to save files in Downloads folder, which normally has effect on Firefox saving temporary files, but Firefox ignores the download folder configured in Safari totally.
(In reply to comment #50)
> I forgot to say that Safari is also configured to save files in Downloads
> folder, which normally has effect on Firefox saving temporary files, but
> Firefox ignores the download folder configured in Safari totally.

See bug 374184 for a temporary solution.
Product: Firefox → Toolkit
So, as far as I can tell, this is working just fine in 3.1.  Can anyone else confirm?
No it doesn't. Creating a fresh profile and opening the options panel still shows 'Desktop' as the pre-defined target location.
Target Milestone: mozilla1.9beta3 → ---
(In reply to comment #54)
> No it doesn't. Creating a fresh profile and opening the options panel still
> shows 'Desktop' as the pre-defined target location.
So, I think that is a bug with the preferences panel, because downloads are in fact going to my download stack on 10.5, but it says Desktop in the preferences.
Well hrm - that is only true if I use open with it seems.
I tried to fix this a while ago and the pref/download code that governs this is a total mess. I'm not surprised that testing yields inconsistent results. Unless someone rewrote it since I last looked, this isn't an easy fix.
This (In reply to comment #57)
> I tried to fix this a while ago and the pref/download code that governs this is
> a total mess. I'm not surprised that testing yields inconsistent results.
> Unless someone rewrote it since I last looked, this isn't an easy fix.

This code was overhauled quite a bit for 3.0 when we dealt with the new Vista downloads folder. The prefs are documented clearly in prefs code - 

http://mxr.mozilla.org/mozilla-central/source/browser/components/preferences/main.js#178

and there are new interfaces in the download manager which handle retrieving the correct download folder - 

http://mxr.mozilla.org/mozilla-central/source/toolkit/components/downloads/src/nsDownloadManager.cpp#1235

Fx now uses these throughout. It should be pretty easy to figure out what's going on for OSX and patch it up.
Also note there are some quirks to the osx download folder selection, which the download manager code attempts to deal with - 

http://mxr.mozilla.org/mozilla-central/source/xpcom/io/nsDirectoryService.cpp#917
I think it is unacceptable that we don't use Mac OS X 10.5's user download folder by default. This should probably block release.
Assignee: joshmoz → nobody
Status: ASSIGNED → NEW
Flags: blocking1.9.1?
Severity: minor → normal
Priority: P4 → P2
Comment on attachment 286082 [details] [diff] [review]
trunk fix v1.0

This is the fix we'd want now.
Attachment #286082 - Attachment is obsolete: false
Attachment #286082 - Flags: ui-review?(beltzner)
Attachment #286082 - Flags: review?(gavin.sharp)
Assignee: nobody → joshmoz
Target Milestone: --- → mozilla1.9.2a1
Attachment #286024 - Attachment is obsolete: true
Flags: blocking1.9.1? → blocking1.9.1+
Whiteboard: [polish-easy]
Attachment #286082 - Flags: ui-review?(beltzner) → ui-review+
Blocks: 475830
Attached patch v2.0Splinter Review
Per discussion on irc with gavin and beltzner, we are going to change this preference to 1 everywhere.

Additionally, filing a follow-up to make XP go to My Documents/Downloads instead of Desktop/Downloads (bug 475830)
Assignee: joshmoz → sdwilsh
Attachment #286082 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #359395 - Flags: review?(gavin.sharp)
Attachment #286082 - Flags: review?(gavin.sharp)
Attachment #359395 - Flags: review?(gavin.sharp) → review+
http://hg.mozilla.org/mozilla-central/rev/0dbe917bed2c
Status: ASSIGNED → RESOLVED
Closed: 17 years ago15 years ago
Resolution: --- → FIXED
Verified on trunk and 1.9.1 with:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090129 Minefield/3.2a1pre

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090130 Shiretoko/3.1b3pre

Shawn, how is it handled on 10.4? Do we always rely on the Safari setting and the desktop folder is chosen?
Status: RESOLVED → VERIFIED
Not sure if it's this bug, but some reason everything is downloading to Desktop/Downloads for me on 10.5.6.

browser.download.folderList is 1

Preferences screen shows Save files to "Downloads" where browse shows it's the directory under Desktop.
Edward, which version are you using? And does it happen for you after the creation of a fresh profile? For me its correctly saved under ~/Downloads.
Seems like anything since 20090129 builds download to ~/Desktop/Downloads even on a new profile for me.

Just a sanity check, Safari still downloads to ~/Downloads.
Depends on: 476174
https://litmus.mozilla.org/show_test.cgi?id=7492 added to the Leopard specific test suite.
Flags: in-litmus? → in-litmus+
Confirm I'm seeing this behavior.  I repro'd it by clicking on a link to a word doc and when prompted by firefox, I chose to open it as opposed to saving it.

MacOSX 10.5.6, Firefox 3.0.6 
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.6) Gecko/2009011912 Firefox/3.0.6
Ryan: This bug isn't fixed on the 1.9.0.x branch (Firefox 3.0.6), only for 1.9.1 (Firefox 3.1) and the trunk. 

(In reply to comment #72)
> Confirm I'm seeing this behavior.  I repro'd it by clicking on a link to a word
> doc and when prompted by firefox, I chose to open it as opposed to saving it.
> 
> MacOSX 10.5.6, Firefox 3.0.6 
> Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.6)
> Gecko/2009011912 Firefox/3.0.6
I'm new here and not sure if I should even be posting this, but from what I'm reading this is verified fixed in the 3.1 beta?  I downloaded that version just to test, but it is still downloading to the default "downloads" folder when I open something using the "open with" option.  Please note, that I have changed the default download folder to something else.. IE.. I don't want these "temp files" to go to the "downloads" folder, I want them to go to the folder I specified...  See these comments: 

  -------  Comment #49 From  Marcus Münch   2008-02-23 02:46:22 PST   (-) [reply] -------

Just to file it: Firefox 3.0 Beta 3 on OS X 10.5 also ignores the download
folder for files sent to helper apps. Example: I have configured my Firefox to
open M3U-Files with VLC. I also have my Firefox configured to download all
files to the Leopard download folder. But all M3U files that Firefox downloads
and sends to VLC are stored on the desktop. I would expect a behaviour as on
Windows, where those temporary files are stored in the temp folder.
(In reply to comment #74)
> I'm new here and not sure if I should even be posting this, but from what I'm
> reading this is verified fixed in the 3.1 beta?  I downloaded that version just
> to test, but it is still downloading to the default "downloads" folder when I
> open something using the "open with" option.  Please note, that I have changed
> the default download folder to something else.. IE.. I don't want these "temp
> files" to go to the "downloads" folder, I want them to go to the folder I
> specified...  See these comments: 
That's not this bug.  You might be looking for bug 311292.
This bug's priority relative to the set of other polish bugs is:
P2 - Polish issue that is in a secondary interface, occasionally encountered, and is easily identifiable.

only effects download interactions, so occasionally encountered.
Whiteboard: [polish-easy] → [polish-easy][polish-p2]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: