Closed
Bug 566484
Opened 15 years ago
Closed 15 years ago
Replace "Download retention" with "Download history" in Browser preferences
Categories
(SeaMonkey :: Download & File Handling, defect)
SeaMonkey
Download & File Handling
Tracking
(Not tracked)
RESOLVED
FIXED
seamonkey2.1a2
People
(Reporter: rsx11m.pub, Assigned: rsx11m.pub)
References
Details
Attachments
(1 file, 1 obsolete file)
4.23 KB,
patch
|
rsx11m.pub
:
review+
neil
:
superreview+
|
Details | Diff | Splinter Review |
This is a follow-up to bug 487675 which I had on my list for a while. The
label introduced there for the browser.download.manager.retention pref reads "Download retention", thus is accurate with regard to the preference, but somewhat inconsistent with "Download history" defined in sanitize.dtd for the Privacy & Security preferences. The latter follows less the name for the pref but appears to be more intuitive, thus avoiding ambiguities, therefore the proposal to change it in the Browser preferences as well.
This changes the label to "Download history" as proposed, and also changes "Remove downloads" to "Remove list entries" to be more specific what is does
(the term "download" is used just above, thus no need to repeat it here).
It also matches the identifier with the modified entity names.
Assignee: nobody → rsx11m.pub
Status: NEW → ASSIGNED
Attachment #445845 -
Flags: superreview?(neil)
Attachment #445845 -
Flags: review?(iann_bugzilla)
Attachment #445845 -
Flags: review?(iann_bugzilla) → review+
Comment 2•15 years ago
|
||
BTW, I still wonder if the pref UI implemented in bug 487675 is actually mirrored by real download manager UI behavior, as I don't remember implementing functionality for that pref in our UI.
Good point, but it seems to work. I've just changed the setting from "Never"
to "When quitting SeaMonkey", then quit and restarted, and the list was gone.
Comment 4•15 years ago
|
||
(In reply to comment #2)
> BTW, I still wonder if the pref UI implemented in bug 487675 is actually
> mirrored by real download manager UI behavior, as I don't remember implementing
> functionality for that pref in our UI.
It's handled in nsDownloadManager.cpp [GetRetentionBehavior()].
Comment 5•15 years ago
|
||
Right, I just verified that it doesn't need implementation elsewhere. Clearly my bug 487675 comment #0 was somewhat misguided and I did let myself misguide me once again when I re-read it.
Comment 6•15 years ago
|
||
> This changes the label to "Download history" as proposed, and also changes
> "Remove downloads" to "Remove list entries" to be more specific what is does
> (the term "download" is used just above, thus no need to repeat it here).
Well, I don't like "Remove list entries:"... if you don't like "Remove download entries:" I could go with "Remove entries:". Either way the entities could be named removeEntries.label/accesskey.
Label and entity titles changed per Neil's comment #6, it's a bit longer but still fits well into the dialog window (at least on WinXP).
> (comment #4) It's handled in nsDownloadManager.cpp [GetRetentionBehavior()].
I figured that toolkit is taking care of it somewhere.
Carrying forward r=IanN from previous patch.
Attachment #445845 -
Attachment is obsolete: true
Attachment #445943 -
Flags: superreview?(neil)
Attachment #445943 -
Flags: review+
Attachment #445845 -
Flags: superreview?(neil)
Comment 8•15 years ago
|
||
Comment on attachment 445943 [details] [diff] [review]
Proposed patch (v2)
>-<!ENTITY removeDownloads.label "Remove downloads">
[Odd; I was expecting this to end in a :]
Attachment #445943 -
Flags: superreview?(neil) → superreview+
Me too, but neither does any of the other labels followed by some box end
in a colon, thus I kept it this way. Making label styles consistent across preference dialogs may be a bug on its own...
Thanks for the reviews, push on trunk please.
Keywords: checkin-needed
Whiteboard: [c-n: comm-central]
Comment 10•15 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Whiteboard: [c-n: comm-central]
You need to log in
before you can comment on or make changes to this bug.
Description
•