Closed
Bug 475830
Opened 16 years ago
Closed 16 years ago
Downloads should end up in My Documents/Downloads for winxp
Categories
(Toolkit :: Downloads API, defect, P2)
Tracking
()
VERIFIED
FIXED
mozilla1.9.2a1
People
(Reporter: sdwilsh, Assigned: sdwilsh)
References
Details
(Keywords: verified1.9.1)
Attachments
(1 file)
1.88 KB,
patch
|
Gavin
:
review+
|
Details | Diff | Splinter Review |
Downloads should end up in My Documents/Downloads and not in Desktop/Downloads for windows XP
Flags: blocking1.9.1?
Updated•16 years ago
|
Flags: in-litmus?
Updated•16 years ago
|
OS: All → Windows XP
Hardware: All → x86
Assignee | ||
Comment 1•16 years ago
|
||
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.
Comment 2•16 years ago
|
||
You can just avoid moving the folder creation code for now, I guess.
Assignee | ||
Comment 3•16 years ago
|
||
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)
Assignee | ||
Updated•16 years ago
|
Whiteboard: [needs review gavin]
Updated•16 years ago
|
Attachment #359414 -
Flags: review?(gavin.sharp) → review+
Comment 4•16 years ago
|
||
(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]
Assignee | ||
Comment 5•16 years ago
|
||
Comment on attachment 359414 [details] [diff] [review]
v1.0
Asking for approval if we don't get blocking+
Attachment #359414 -
Flags: approval1.9.1?
Assignee | ||
Updated•16 years ago
|
Whiteboard: [needs approval]
Assignee | ||
Comment 6•16 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Comment 7•16 years ago
|
||
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
Comment 9•16 years ago
|
||
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
Updated•16 years ago
|
Flags: blocking1.9.1? → blocking1.9.1+
Priority: -- → P2
Whiteboard: [needs approval]
Assignee | ||
Comment 10•16 years ago
|
||
Comment on attachment 359414 [details] [diff] [review]
v1.0
Don't need approval anymore
Attachment #359414 -
Flags: approval1.9.1?
Assignee | ||
Comment 11•16 years ago
|
||
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
Keywords: fixed1.9.1
Comment 12•16 years ago
|
||
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.
Keywords: fixed1.9.1 → verified1.9.1
You need to log in
before you can comment on or make changes to this bug.
Description
•