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)
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)
2.66 KB,
patch
|
Gavin
:
review+
|
Details | Diff | Splinter Review |
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•17 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•17 years ago
|
||
Josh, do you plan on working on this?
Comment 4•17 years ago
|
||
Thunderbird equivalent: bug 385438
Comment 6•17 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•17 years ago
|
||
There is no Toolkit->Download Manager. Sadly, we just get to dupe bugs here.
Comment 8•17 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 10•17 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?
Updated•17 years ago
|
Flags: blocking-firefox3? → blocking-firefox3+
Updated•17 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
Comment 11•17 years ago
|
||
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•17 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.
Comment 13•17 years ago
|
||
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
Comment 14•17 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 ...
Updated•17 years ago
|
Resolution: WORKSFORME → FIXED
Assignee | ||
Comment 15•17 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
Comment 16•17 years ago
|
||
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•17 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?
Updated•17 years ago
|
Flags: in-litmus?
Comment 18•17 years ago
|
||
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•17 years ago
|
||
Litmus Triage Team: marcia will handle this test case.
Updated•17 years ago
|
Target Milestone: Firefox 3 M9 → Firefox 3 M10
Comment 20•17 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?
Comment 21•17 years ago
|
||
I just installed Leopard and then immediately installed Firefox 2.0.0.7 and it's defaulting to the Desktop for downloads.
Comment 22•17 years ago
|
||
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•17 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•17 years ago
|
||
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•17 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•17 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•17 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•17 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•17 years ago
|
||
Attachment #286082 -
Flags: review?(edilee)
Comment 30•17 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•17 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•17 years ago
|
||
nsExternalHelperAppService.cpp should probably be updated as well for "Open With..." downloads.
Comment 33•17 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•17 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•17 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•17 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•17 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•17 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.
Comment 39•17 years ago
|
||
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•17 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.
Comment 41•17 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•17 years ago
|
Attachment #286024 -
Flags: review?(jmathies) → review-
Comment 42•17 years ago
|
||
I have a new patch coming up that does things in a better way.
Comment 43•17 years ago
|
||
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•17 years ago
|
Target Milestone: Firefox 3 M10 → Firefox 3 M11
Comment 44•17 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•17 years ago
|
Priority: -- → P4
Updated•17 years ago
|
Flags: blocking1.8.1.10? → blocking1.8.1.11?
Updated•17 years ago
|
Hardware: Macintosh → All
Comment 45•17 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.
Comment 46•17 years ago
|
||
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+
Comment 47•17 years ago
|
||
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•16 years ago
|
||
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•16 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•16 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.
Comment 51•16 years ago
|
||
(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.
Updated•16 years ago
|
Product: Firefox → Toolkit
Assignee | ||
Comment 53•16 years ago
|
||
So, as far as I can tell, this is working just fine in 3.1. Can anyone else confirm?
Comment 54•16 years ago
|
||
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•16 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•16 years ago
|
||
Well hrm - that is only true if I use open with it seems.
Comment 57•16 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•16 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•16 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
Comment 62•15 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?
Assignee | ||
Comment 63•15 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•15 years ago
|
Assignee: nobody → joshmoz
Target Milestone: --- → mozilla1.9.2a1
Assignee | ||
Updated•15 years ago
|
Attachment #286024 -
Attachment is obsolete: true
Updated•15 years ago
|
Flags: blocking1.9.1? → blocking1.9.1+
Whiteboard: [polish-easy]
Updated•15 years ago
|
Attachment #286082 -
Flags: ui-review?(beltzner) → ui-review+
Assignee | ||
Comment 64•15 years ago
|
||
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)
Updated•15 years ago
|
Attachment #359395 -
Flags: review?(gavin.sharp) → review+
Assignee | ||
Comment 65•15 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/0dbe917bed2c
Status: ASSIGNED → RESOLVED
Closed: 17 years ago → 15 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 66•15 years ago
|
||
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/b1203dd0b117
Keywords: fixed1.9.1
Comment 67•15 years ago
|
||
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•15 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.
Comment 69•15 years ago
|
||
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•15 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.
Comment 71•15 years ago
|
||
https://litmus.mozilla.org/show_test.cgi?id=7492 added to the Leopard specific test suite.
Flags: in-litmus? → in-litmus+
Comment 72•15 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
Comment 73•15 years ago
|
||
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•15 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•15 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.
Comment 76•15 years ago
|
||
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.
Description
•