Last Comment Bug 384068 - [10.5] Firefox should download files to Leopard's Download Stack by default
: [10.5] Firefox should download files to Leopard's Download Stack by default
Status: VERIFIED FIXED
[polish-easy][polish-p2]
: verified1.9.1
Product: Toolkit
Classification: Components
Component: Download Manager (show other bugs)
: Trunk
: All Mac OS X
: P2 normal with 8 votes (vote)
: mozilla1.9.2a1
Assigned To: Shawn Wilsher :sdwilsh
:
Mentors:
http://www.apple.com/macosx/leopard/f...
: 385438 423855 474235 474546 (view as bug list)
Depends on: 454242 476174
Blocks: 402520 475830
  Show dependency treegraph
 
Reported: 2007-06-11 14:32 PDT by Kroc Camen
Modified: 2009-06-23 01:22 PDT (History)
37 users (show)
mbeltzner: blocking1.9.1+
mconnor: blocking1.9-
mconnor: wanted1.9+
dveditz: blocking1.8.1.12-
mscott: wanted1.8.1.x?
mozillamarcia.knous: in‑litmus+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
fix v1.0 (5.14 KB, patch)
2007-10-23 22:29 PDT, Josh Aas
no flags Details | Diff | Splinter Review
fix v1.1 (5.71 KB, patch)
2007-10-24 09:57 PDT, Josh Aas
jmathies: review-
Details | Diff | Splinter Review
trunk fix v1.0 (1.19 KB, patch)
2007-10-24 16:33 PDT, Josh Aas
mbeltzner: ui‑review+
Details | Diff | Splinter Review
v2.0 (2.66 KB, patch)
2009-01-28 15:37 PST, Shawn Wilsher :sdwilsh
gavin.sharp: review+
Details | Diff | Splinter Review

Description Kroc Camen 2007-06-11 14:32:22 PDT
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.
Comment 1 Zach Lipton [:zach] 2007-06-15 13:43:25 PDT
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. 
Comment 2 Shawn Wilsher :sdwilsh 2007-06-16 15:06:44 PDT
Josh, do you plan on working on this?
Comment 3 Josh Aas 2007-06-17 11:49:03 PDT
Yes
Comment 4 Jean-Michel Reghem 2007-06-22 01:32:34 PDT
Thunderbird equivalent: bug 385438 
Comment 5 Shawn Wilsher :sdwilsh 2007-06-22 08:42:33 PDT
*** Bug 385438 has been marked as a duplicate of this bug. ***
Comment 6 Jean-Michel Reghem 2007-06-24 23:39:53 PDT
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?
Comment 7 Shawn Wilsher :sdwilsh 2007-06-25 06:15:31 PDT
There is no Toolkit->Download Manager.  Sadly, we just get to dupe bugs here.
Comment 8 Scott MacGregor 2007-06-26 18:38:23 PDT
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
Comment 9 Josh Aas 2007-06-26 20:56:56 PDT
Yes, we should probably port to the branch.
Comment 10 Scott MacGregor 2007-06-26 21:35:56 PDT
nominating for wanted1.8.1.x. This is something we'll want to port for Leopard compatibility when we have a fix.
Comment 11 Colin Barrett [:cbarrett] 2007-08-22 15:02:47 PDT
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.
Comment 12 Shawn Wilsher :sdwilsh 2007-08-22 15:04:30 PDT
I think Jim ended up fixing it when he fixed it for Vista.  Colin - if you want to resolve this, that'd be great.
Comment 13 Colin Barrett [:cbarrett] 2007-08-22 15:12:52 PDT
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.
Comment 14 Jean-Michel Reghem 2007-08-23 00:47:21 PDT
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 ...
Comment 15 Shawn Wilsher :sdwilsh 2007-08-23 11:18:36 PDT
Unless we have a bug # that this was fixed by or there's a patch in this bug that fixed it, it's WORKSFORME
Comment 16 Samuel Sidler (old account; do not CC) 2007-08-27 23:18:32 PDT
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.
Comment 17 Jean-Michel Reghem 2007-08-28 01:03:27 PDT
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?
Comment 18 Colin Barrett [:cbarrett] 2007-08-28 10:02:49 PDT
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).
Comment 19 Marcia Knous [:marcia - use ni] 2007-09-12 12:38:03 PDT
Litmus Triage Team: marcia will handle this test case.
Comment 20 Josh Aas 2007-10-15 22:13:36 PDT
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?
Comment 21 Eric Shepherd [:sheppy] 2007-10-18 13:12:40 PDT
I just installed Leopard and then immediately installed Firefox 2.0.0.7 and it's defaulting to the Desktop for downloads.
Comment 22 Josh Aas 2007-10-23 22:29:48 PDT
Created attachment 285967 [details] [diff] [review]
fix v1.0

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.
Comment 23 Josh Aas 2007-10-23 22:57:46 PDT
Comment on attachment 285967 [details] [diff] [review]
fix v1.0

Actually, this messes up 10.4. New patch coming up.
Comment 24 Josh Aas 2007-10-24 09:57:33 PDT
Created attachment 286024 [details] [diff] [review]
fix v1.1

This is a better way to do things. Works perfectly for me on 10.4 and 10.5.
Comment 25 Shawn Wilsher :sdwilsh 2007-10-24 10:13:28 PDT
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)
Comment 26 Josh Aas 2007-10-24 11:05:39 PDT
This patch is for Firefox 2, the 1.8.1 branch. I have made no attempt to fix this on the trunk yet.
Comment 27 Jim Mathies [:jimm] 2007-10-24 11:15:09 PDT
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.
Comment 28 Jim Mathies [:jimm] 2007-10-24 11:22:41 PDT
>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.
Comment 29 Josh Aas 2007-10-24 16:33:17 PDT
Created attachment 286082 [details] [diff] [review]
trunk fix v1.0
Comment 30 Ed Lee :Mardak 2007-10-24 17:37:45 PDT
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?
Comment 31 Josh Aas 2007-10-25 09:28:19 PDT
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.
Comment 32 Shawn Wilsher :sdwilsh 2007-10-27 09:57:33 PDT
nsExternalHelperAppService.cpp should probably be updated as well for "Open With..." downloads.
Comment 33 James Kebinger 2007-10-27 13:21:17 PDT
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.
Comment 34 Jim Mathies [:jimm] 2007-10-27 13:36:34 PDT
>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 35 Shawn Wilsher :sdwilsh 2007-10-29 11:29:26 PDT
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.
Comment 36 Shawn Wilsher :sdwilsh 2007-10-29 11:33:12 PDT
For clarity:
sdwilsh: so, it goes to the desktop still on 10.4, but goes to the stack on 10.5?
josh: yes
Comment 37 Jim Mathies [:jimm] 2007-10-30 11:59:26 PDT
>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.
Comment 38 Jim Mathies [:jimm] 2007-10-30 12:15:06 PDT
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.
Comment 39 Fred Wenzel [:wenzel] 2007-11-02 09:30:17 PDT
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.
Comment 40 Shawn Wilsher :sdwilsh 2007-11-02 11:04:19 PDT
(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.
Comment 41 Josh Aas 2007-11-08 06:58:10 PST
(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.
Comment 42 Josh Aas 2007-11-08 11:03:31 PST
I have a new patch coming up that does things in a better way.
Comment 43 Daniel Veditz [:dveditz] 2007-11-08 11:34:51 PST
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?
Comment 44 Josh Aas 2007-11-08 12:58:23 PST
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.
Comment 45 Johannes Schaub 2007-11-20 12:07:34 PST
... 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.
Comment 46 Mike Connor [:mconnor] 2007-11-28 10:21:08 PST
Very much wanted, but if this doesn't happen for some reason it will not block the release.
Comment 47 Colin Barrett [:cbarrett] 2007-11-28 10:50:06 PST
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.
Comment 48 Daniel Veditz [:dveditz] 2008-01-07 15:51:32 PST
If it's not even blocking for trunk it's not going to block a security release.
Comment 49 Marcus Münch 2008-02-23 02:46:22 PST
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.
Comment 50 Marcus Münch 2008-02-23 07:54:54 PST
(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.
Comment 51 Henrik Skupin (:whimboo) 2008-02-23 09:12:10 PST
(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.
Comment 52 Phil Ringnalda (:philor) 2008-03-19 11:42:02 PDT
*** Bug 423855 has been marked as a duplicate of this bug. ***
Comment 53 Shawn Wilsher :sdwilsh 2008-11-03 22:11:49 PST
So, as far as I can tell, this is working just fine in 3.1.  Can anyone else confirm?
Comment 54 Henrik Skupin (:whimboo) 2008-11-06 13:55:51 PST
No it doesn't. Creating a fresh profile and opening the options panel still shows 'Desktop' as the pre-defined target location.
Comment 55 Shawn Wilsher :sdwilsh 2008-11-06 13:59:53 PST
(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.
Comment 56 Shawn Wilsher :sdwilsh 2008-11-06 14:00:33 PST
Well hrm - that is only true if I use open with it seems.
Comment 57 Josh Aas 2008-11-06 20:38:33 PST
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.
Comment 58 Jim Mathies [:jimm] 2008-11-07 05:53:54 PST
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.
Comment 59 Jim Mathies [:jimm] 2008-11-07 06:02:57 PST
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
Comment 60 Arie Paap [:wildmyron] 2009-01-21 01:23:15 PST
*** Bug 474546 has been marked as a duplicate of this bug. ***
Comment 61 Josh Aas 2009-01-26 10:19:43 PST
*** Bug 474235 has been marked as a duplicate of this bug. ***
Comment 62 Josh Aas 2009-01-26 10:20:20 PST
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.
Comment 63 Shawn Wilsher :sdwilsh 2009-01-27 10:47:11 PST
Comment on attachment 286082 [details] [diff] [review]
trunk fix v1.0

This is the fix we'd want now.
Comment 64 Shawn Wilsher :sdwilsh 2009-01-28 15:37:06 PST
Created attachment 359395 [details] [diff] [review]
v2.0

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)
Comment 65 Shawn Wilsher :sdwilsh 2009-01-28 16:07:12 PST
http://hg.mozilla.org/mozilla-central/rev/0dbe917bed2c
Comment 66 Shawn Wilsher :sdwilsh 2009-01-29 10:06:47 PST
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/b1203dd0b117
Comment 67 Henrik Skupin (:whimboo) 2009-01-30 07:19:08 PST
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?
Comment 68 Ed Lee :Mardak 2009-01-30 08:08:23 PST
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.
Comment 69 Henrik Skupin (:whimboo) 2009-01-30 08:23:27 PST
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.
Comment 70 Ed Lee :Mardak 2009-01-30 08:27:10 PST
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.
Comment 71 Marcia Knous [:marcia - use ni] 2009-02-03 15:42:31 PST
https://litmus.mozilla.org/show_test.cgi?id=7492 added to the Leopard specific test suite.
Comment 72 Ryan Whitney 2009-02-27 16:00:50 PST
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
Comment 73 Marcia Knous [:marcia - use ni] 2009-02-27 16:05:36 PST
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
Comment 74 Paul 2009-03-01 19:47:49 PST
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.
Comment 75 Shawn Wilsher :sdwilsh 2009-03-01 19:50:57 PST
(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.
Comment 76 Alex Faaborg [:faaborg] (Firefox UX) 2009-06-23 01:22:00 PDT
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.

Note You need to log in before you can comment on or make changes to this bug.