Closed Bug 657218 Opened 10 years ago Closed 10 years ago

UI for new archive granularity uses false accesskey entity for keepArchives

Categories

(Thunderbird :: Account Manager, defect)

defect
Not set
normal

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)

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: --- → ?
Attached 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: 10 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.
Attached 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.