UI for new archive granularity uses false accesskey entity for keepArchives

RESOLVED FIXED in Thunderbird 5.0b1

Status

defect
RESOLVED FIXED
8 years ago
8 years ago

People

(Reporter: bugzilla, Assigned: rsx11m.pub)

Tracking

Trunk
Thunderbird 5.0b1
Dependency tree / graph

Firefox Tracking Flags

(blocking-thunderbird5.0 beta1+)

Details

Attachments

(1 attachment, 1 obsolete attachment)

1.00 KB, patch
rsx11m.pub
: review+
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;
Blocks: 607295
This should block 3.3 as it affects localizers.
blocking-thunderbird5.0: --- → ?
Posted patch Easy fix (obsolete) — Splinter Review
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)
Thankfully, keepArchives.accesskey is already defined and we don't have to worry about the string freeze.
blocking-thunderbird5.0: ? → alpha4+
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+
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: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 3.4
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.
Posted patch Final patchSplinter Review
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 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+
Target Milestone: Thunderbird 3.4 → Thunderbird 3.3a4
You need to log in before you can comment on or make changes to this bug.