40759 - Mail prefs dialog: implement mnemonics

Status: RESOLVED FIXED

(SeaMonkey :: MailNews: Message Display, defect, P3)

Description

[laurel]

refer to mail prefs spec:
http://gooey/client/5.0/specs/mail/Prefs/Preferences.html

Mnenmonics have been added in the current revision of the mail prefs ui spec.
Please implement -- Win32 for sure. What about linux? 4.x had mnemonics in
menus, but not in dialogs (at least I haven't found any).

Comment 1

[scottputterman]

moving to future milestone.

Comment 2

[sairuh (rarely reading bugmail)]

adding self and aaron leventhal, as this would affect accessibility. now gotta
check to see if this is already covered by a bug in the Browser: Preferences
component... [am assuming this bug is referring to access keys, another name
afaik for mnemonics...]

Comment 3

[Jesse Ruderman]

Right now bug 959 (make accesskeys for xul work) blocks bug 18575 (metabug for 
keyboard access to prefs), but I don't know if there's a bug for adding more 
accesskeys to browser prefs panels.  For now, making this bug block 18575, 
although it might make more sense to have an extra metabug in between for "add 
mnemonics to prefs panels".

Comment 4

[sairuh (rarely reading bugmail)]

seth, would this belong to you...?

Comment 5

[scottputterman]

reassigning to ssu.  However, unless the ability to access mnemonics gets fixed,
there's no sense in implementing this.

Comment 6

[Stefan Borggraefe]

Attachment: Patch

In the meantime there were accesskeys added for most of the options in the
mailnews prefs. This patch adds the remaining accesskeys and fixes some (e.g.
the accesskey sendDefaultCharset.accesskey was "h" which conflicts with the
accesskey for the Help-button). Furthermore I made the accesskeys for "Return
Receipts" consistend with the patch for the same pref pane in "Mail &
Newsgroups account settings..." in bug 68341.

I also removed some unused strings when I spotted them. There were quite a few
of them.

Comment 7

[Stefan Borggraefe]

Taking bug.

Comment 8

[[e-mail]]

Comment on attachment 136106 [details] [diff] [review]
Patch

I don't agree with all of your keys.

System New &Mail Sound

Leave it in my &Inbox

&Allow return receipts for some messages

&Do not send my unsent messages
Do &not download messages for offline use
(I'm not sure whether to swap these or not)

Confirm when using &keyboard shortcut to send message
(Rather than changing the other key)

Be careful about removing "unused" strings - they may be needed later.

Comment 9

[Stefan Borggraefe]

Ok, I did a little research about the unused strings. I think all of them should
be removed.

>-<!ENTITY dsn.label                    "A delivery receipt from the receiving
server (DSN)">
>-<!ENTITY dsn.accesskey                "d">
>-<!ENTITY mdn.label                    "A read receipt, notifying me when
recipients display the message (MDN)">
>-<!ENTITY mdn.accesskey                "m">
>-<!ENTITY both.label                   "Both types of receipt">
>-<!ENTITY both.accesskey               "b">

These were forgotten when bug 38308 was fixed.

>-<!ENTITY custom.label                 "Customize...">
>-<!ENTITY custom.accesskey             "c">

This was for a buttton that used to open the dialog custreceipt.xul. This file
is no longer in the tree.

>-<!ENTITY pane.description                     "Composing mail messages">

This was used in pref-composing_messages.xul till revision 1.2 and was then
removed for "skinability fixes".
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=pref-composing_messages.xul&branch=&root=/cvsroot&subdir=mozilla/mailnews/compose/prefs/resources/content&command=DIFF_FRAMESET&rev1=1.2&rev2=1.3
The same happened to pane.description in pref-addressing.dtd.

>-<!ENTITY quoted.label                         "Quoted">
>-<!ENTITY quoted.accesskey                     "q">

Leftover from bug 37932.

>-<!ENTITY readingMessagesHeader.label          "For incoming messages">
>-<!ENTITY messageWrapping.label                "Message Wrapping">
>-<!ENTITY wrapInMsg.label                      "Wrap plain text messages to fit
window width">
>-<!ENTITY wrapInMsg.accesskey                  "w">

The message wrapping for incoming messages was moved to the "Message Display"
pane at one point of time. pref-composing_messages.dtd is the wrong place for
this. With these option removed from this pane the category heading "Message
Wrapping" is no longer needed, too.

>-<!ENTITY use8Bits.label                       "Send messages that use 8-bit
characters">
>-<!ENTITY asIs.label                           "As is (does not work well with
some mail servers)">

These were replaced by useMIME.label. See
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=suresh%25netscape.com&whotype=match&sortby=Date&hours=2&date=explicit&mindate=05%2F16%2F2000+00%3A00%3A00&maxdate=05%2F16%2F2000+23%3A59%3A59&cvsroot=%2Fcvsroot

>-<!ENTITY languagesText.label				  "Use the following character coding as the
default for composing messages:">

See http://bugzilla.mozilla.org/show_bug.cgi?id=38092#c16.

>-<!ENTITY window.title           "Addressing">

This was in pref-addressing.dtd since revision 1.1 and it was never used. I
don't think a "window.title" needs to be in a DTD for a pane.

>-<!ENTITY pinpoint.label         "Pinpoint Addressing">
>-<!ENTITY lookFor.label          "Look for addresses in the following:">
>-<!ENTITY padCheck.label         "Address Books">
>-<!ENTITY padCheck.accesskey     "a">
>-<!ENTITY dirCheck.label         "Directory Server">
>-<!ENTITY dirCheck.accesskey     "d">
>-<!ENTITY mulFound.label         "When there are multiple addresses found:">
>-<!ENTITY showList.label         "Show me a list of choices">
>-<!ENTITY showList.accesskey     "s">
>-<!ENTITY acceptList.label       "Accept what I have typed">
>-<!ENTITY acceptList.accesskey   "c">
>-<!ENTITY oneMatch.label         "If there is one match in your personal
address books:">
>-<!ENTITY useAddress.label       "Use the address and do not search in the
directory">
>-<!ENTITY useAddress.accesskey   "u">

Leftover from bug 37979.

Comment 10

[Stefan Borggraefe]

Attachment: Patch V1.1

> &Allow return receipts for some messages

I chosed the other accesskey because I wanted the keys in this pref-pane be the
same as in the account specific settings in the Account Manager. Because of
this, I can't use "A" since this is already used for "Add Account" there. (See
bug 68341).

> &Do not send my unsent messages
> Do &not download messages for offline use
> (I'm not sure whether to swap these or not)

I don't see the problem here. So I left the keys as they were in the last
revision of the patch for now. I think they are just fine. ;-)

I changed the other keys according to the review comments.

Comment 11

[[e-mail]]

Comment on attachment 136446 [details] [diff] [review]
Patch V1.1

Nice homework :-)

Comment 12

[Boris Zbarsky [:bzbarsky]]

I'm not likely to get to this review any time soon (we're talking weeks).

Comment 13

[[e-mail]]

Comment on attachment 136446 [details] [diff] [review]
Patch V1.1

You're not having much luck, are you? Maybe Seth will sr it for you...

Comment 14

[Stefan Borggraefe]

Comment on attachment 136446 [details] [diff] [review]
Patch V1.1

Patch bitrotted. :-(

Comment 15

[Stefan Borggraefe]

Attachment: Updated patch

Comment 16

[Stefan Borggraefe]

Comment on attachment 142614 [details] [diff] [review]
Updated patch

The patch is just updated to fix the bitrot and otherwise unchanged.

So transfering r=neil to this patch and asking bz for sr.

Boris: This is just a trivial patch that adds missing accesskeys, correct some
doubled accesskeys and removes unused strings. See comment 9.

Comment 17

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 142614 [details] [diff] [review]
Updated patch

rs=bzbarsky.  I didn't read through the patch too closely, since I wouldn't be
able to tell whether the details are right anyway... the overall patch seems
fine.

Comment 18

[Stefan Borggraefe]

Checked in by mconnor. Marking FIXED. :-)

Comment 19

[Stefan Borggraefe]

*** Bug 154252 has been marked as a duplicate of this bug. ***