The default bug view has changed. See this FAQ.

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

VERIFIED FIXED in mozilla1.9.2a1

Status

()

Toolkit
Downloads API
P2
normal
VERIFIED FIXED
10 years ago
8 years ago

People

(Reporter: Kroc Camen, Assigned: sdwilsh)

Tracking

({verified1.9.1})

Trunk
mozilla1.9.2a1
All
Mac OS X
verified1.9.1
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9.1 +
blocking1.9 -
wanted1.9 +
blocking1.8.1.12 -
wanted1.8.1.x ?
in-litmus +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [polish-easy][polish-p2], URL)

Attachments

(1 attachment, 3 obsolete attachments)

(Reporter)

Description

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

10 years ago
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
(Assignee)

Comment 2

10 years ago
Josh, do you plan on working on this?

Comment 3

10 years ago
Yes

Comment 4

10 years ago
Thunderbird equivalent: bug 385438 
(Assignee)

Updated

10 years ago
Duplicate of this bug: 385438

Comment 6

10 years ago
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?
(Assignee)

Comment 7

10 years ago
There is no Toolkit->Download Manager.  Sadly, we just get to dupe bugs here.

Comment 8

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

10 years ago
Yes, we should probably port to the branch.

Comment 10

10 years ago
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+

Updated

10 years ago
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.
(Assignee)

Comment 12

10 years ago
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
Last Resolved: 10 years ago
Resolution: --- → WORKSFORME

Comment 14

10 years ago
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
(Assignee)

Comment 15

10 years ago
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 → ---

Comment 17

10 years ago
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?
Flags: in-litmus?
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.

Updated

10 years ago
Target Milestone: Firefox 3 M9 → Firefox 3 M10

Comment 20

10 years ago
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.

Comment 22

10 years ago
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.
Attachment #285967 - Flags: review?(mano)

Comment 23

10 years ago
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)

Comment 24

10 years ago
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.
Attachment #286024 - Flags: review?(mano)
(Assignee)

Comment 25

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

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

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

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

10 years ago
Created attachment 286082 [details] [diff] [review]
trunk fix v1.0
Attachment #286082 - Flags: review?(edilee)

Comment 30

10 years ago
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 31

10 years ago
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)
(Assignee)

Comment 32

10 years ago
nsExternalHelperAppService.cpp should probably be updated as well for "Open With..." downloads.

Comment 33

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

10 years ago
>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.
(Assignee)

Comment 35

10 years ago
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)
(Assignee)

Comment 36

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

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

10 years ago
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.
(Assignee)

Comment 40

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

Updated

10 years ago
Blocks: 402520

Updated

10 years ago
Flags: blocking1.8.1.10?

Comment 41

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

Updated

10 years ago
Attachment #286024 - Flags: review?(jmathies) → review-

Comment 42

10 years ago
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?

Updated

10 years ago
Target Milestone: Firefox 3 M10 → Firefox 3 M11

Comment 44

10 years ago
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.

Updated

10 years ago
Priority: -- → P4
Flags: blocking1.8.1.10? → blocking1.8.1.11?
Hardware: Macintosh → All

Comment 45

10 years ago
... 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-

Comment 49

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

9 years ago
(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.
Duplicate of this bug: 423855
Product: Firefox → Toolkit
(Assignee)

Comment 53

9 years ago
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 → ---
(Assignee)

Comment 55

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

Comment 56

9 years ago
Well hrm - that is only true if I use open with it seems.

Comment 57

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

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

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

Updated

8 years ago
Duplicate of this bug: 474546

Updated

8 years ago
Duplicate of this bug: 474235

Comment 62

8 years ago
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?

Updated

8 years ago
Severity: minor → normal
Priority: P4 → P2
Depends on: 454242
(Assignee)

Comment 63

8 years ago
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)

Updated

8 years ago
Assignee: nobody → joshmoz
Target Milestone: --- → mozilla1.9.2a1
(Assignee)

Updated

8 years ago
Attachment #286024 - Attachment is obsolete: true
Flags: blocking1.9.1? → blocking1.9.1+
Whiteboard: [polish-easy]
Attachment #286082 - Flags: ui-review?(beltzner) → ui-review+
(Assignee)

Updated

8 years ago
Blocks: 475830
(Assignee)

Comment 64

8 years ago
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)
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+
(Assignee)

Comment 65

8 years ago
http://hg.mozilla.org/mozilla-central/rev/0dbe917bed2c
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago8 years ago
Resolution: --- → FIXED
(Assignee)

Comment 66

8 years ago
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/b1203dd0b117
Keywords: fixed1.9.1
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
Keywords: fixed1.9.1 → verified1.9.1

Comment 68

8 years ago
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.

Comment 70

8 years ago
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.

Updated

8 years ago
Depends on: 476174
https://litmus.mozilla.org/show_test.cgi?id=7492 added to the Leopard specific test suite.
Flags: in-litmus? → in-litmus+

Comment 72

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

Comment 74

8 years ago
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.
(Assignee)

Comment 75

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