Closed Bug 475830 Opened 13 years ago Closed 13 years ago
Downloads should end up in My Documents/Downloads for winxp
Downloads should end up in My Documents/Downloads and not in Desktop/Downloads for windows XP
13 years ago
13 years ago
OS: All → Windows XP
Hardware: All → x86
There's a bit of an issue with making this change in xpcom/io/SpecialSystemDirectory.cpp as originally discussed with gavin. We need to localize the downloads folder name, and I'm not 100% sure we can get a string bundle in that code (and then, we'd be breaking string freeze for 3.1). We can fix this strictly in the download manager code, however. Awaiting input on how gavin wants this done.
You can just avoid moving the folder creation code for now, I guess.
This only makes changes in nsDownloadManager.cpp. I figure it doesn't make sense to have the xpcom code fall back to My Documents as the download folder for XP/2k, and it could break any add-ons that rely on it now.
Attachment #359414 - Flags: review?(gavin.sharp)
Attachment #359414 - Flags: review?(gavin.sharp) → review+
(In reply to comment #3) > I figure it doesn't make sense to have the xpcom code fall back to My Documents > as the download folder for XP/2k, and it could break any add-ons that rely on > it now. Yeah, makes sense.
Whiteboard: [needs review gavin]
Comment on attachment 359414 [details] [diff] [review] v1.0 Asking for approval if we don't get blocking+
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Shawn, how can I verify this change? I suspect that no-one should notice something when saving a file in a fresh profile. Currently we already use the "download" folder under the user profile. So do we had to adjust it because of bug 384068?
"Downloads" folder should not be created if/when download is "Desktop" or other folder ? see https://bugzilla.mozilla.org/show_bug.cgi?id=474718#c4
Thanks for the hint. I can verify the fix with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090130 Minefield/3.2a1pre
Status: RESOLVED → VERIFIED
Flags: blocking1.9.1? → blocking1.9.1+
Priority: -- → P2
Whiteboard: [needs approval]
Comment on attachment 359414 [details] [diff] [review] v1.0 Don't need approval anymore
Branch didn't have the stuff that was landed for bug 429827, so the patch didn't cleanly apply. Fixed it up and pushed: http://hg.mozilla.org/releases/mozilla-1.9.1/rev/f57bc5673b90
Verified with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090201 Shiretoko/3.1b3pre While testing this patch I've noticed that saving a link to disk leaves the downloaded file with the .part extension on disk. I'll file a new bug on that.
You need to log in before you can comment on or make changes to this bug.