Closed
Bug 657218
Opened 13 years ago
Closed 13 years ago
UI for new archive granularity uses false accesskey entity for keepArchives
Categories
(Thunderbird :: Account Manager, defect)
Thunderbird
Account Manager
Tracking
(blocking-thunderbird5.0 beta1+)
RESOLVED
FIXED
Thunderbird 5.0b1
Tracking | Status | |
---|---|---|
blocking-thunderbird5.0 | --- | beta1+ |
People
(Reporter: Thunderbird_Mail_DE, Assigned: rsx11m.pub)
References
Details
Attachments
(1 file, 1 obsolete file)
1.00 KB,
patch
|
rsx11m.pub
:
review+
standard8
:
approval-thunderbird5.0b1+
|
Details | Diff | Splinter Review |
The following XUL code uses a false accesskey entity in comm-trunk and comm-miramar 2011-05-15 builds: <checkbox wsm_persist="true" id="identity.archiveEnabled" label="&keepArchives.label;" accesskey="&fccMailFolder.accesskey;" prefattribute="value" prefstring="mail.identity.%identitykey%.archive_enabled" oncommand="setupArchiveItems();"/> &fccMailFolder.accesskey; has to be replaced by &keepArchives.accesskey;
This should block 3.3 as it affects localizers.
blocking-thunderbird5.0: --- → ?
Patch based on Alex's observation. I've double-checked all access keys in both am-copiesOverlay.xul and am-archiveoptions.xul for any other wrong definitions, but that appears to be the only one. As a drive-by fix, I've adjusted some code formatting in archiveGranularity to make it consistent (white spaces only).
Assignee: nobody → rsx11m.pub
Attachment #532519 -
Flags: review?(bwinton)
Comment 3•13 years ago
|
||
Thankfully, keepArchives.accesskey is already defined and we don't have to worry about the string freeze.
blocking-thunderbird5.0: ? → alpha4+
Comment 4•13 years ago
|
||
Comment on attachment 532519 [details] [diff] [review] Easy fix >- <radio label="&archiveFlat.label;" accesskey="&archiveFlat.accesskey;" >- class="indent"/> >+ <radio label="&archiveFlat.label;" >+ accesskey="&archiveFlat.accesskey;" class="indent"/> I don't think we need this change. The existing version isn't messy, and it hasn't got anything to do with this bug. r=Standard8 with that removed from the patch.
Attachment #532519 -
Flags: review?(bwinton) → review+
Comment 5•13 years ago
|
||
I checked this in without the extra change ready for today's nightly: http://hg.mozilla.org/comm-central/rev/166b7163d9aa
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 3.4
Updated•13 years ago
|
Attachment #532519 -
Flags: approval-thunderbird3.3?
(In reply to comment #4) > I don't think we need this change. The existing version isn't messy, and it > hasn't got anything to do with this bug. Thanks Mark. I've seen this while scanning through the code and adjusted the white spaces on the fly, certainly no problem to leave it as is.
I don't know if you wanted me to provide an updated patch for easier check-in on the Miramar branch, but here it is.
Attachment #532519 -
Attachment is obsolete: true
Attachment #532519 -
Flags: approval-thunderbird3.3?
Attachment #532645 -
Flags: review+
Attachment #532645 -
Flags: approval-thunderbird3.3?
Comment 8•13 years ago
|
||
Comment on attachment 532645 [details] [diff] [review] Final patch Thanks for the extra patch. Checked in: http://hg.mozilla.org/releases/comm-miramar/rev/f82235c21b19
Attachment #532645 -
Flags: approval-thunderbird3.3? → approval-thunderbird3.3+
Updated•13 years ago
|
Target Milestone: Thunderbird 3.4 → Thunderbird 3.3a4
You need to log in
before you can comment on or make changes to this bug.
Description
•