Overview: In the 3pane window the accelerators for the Message menu should match the spec

.

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

Spec says &Reply to Sender, nc and moz have &Reply. I recommend fixing the spec. If spec stands i'll fix. For news I have to add Reply to Newsgroup. we lose functionality here. You can't reply to Sender and Newsgroups. The menus are deceiving. They say reply to Newsgroup, but in reality it's reply to Newsgroup(s). [Or at least that's the nc4.7 behavior]. Additional Comments? mpt?

The spec is wrong and must be changed. Reply should be either * a submenu (as in the Aphrodite spec), or * one item for whichever command has Ctrl+R for the given message (reply to sender/group), followed by a submenu for the other reply commands. If we followed the spec, we'd never get the GNKSA, because making a personal reply from a newsgroup post to the sender would require manual editing of headers!

The spec has a Reply to Sender menu item that wouldn't require manually editing the headers. I don't see how your MUST have choices make it any different since it sounds like you default behavior is still to have Reply To Sender for mail and Reply to Group for news.

per mail triage: remove nsbeta3 nomination and move to future milestone. For the short term, we will combine items here into three bugs (in 3pane) to address for nsbetat3: 1. delete, change text, move menuitems; 2. enable/disable and text changes on context (dynamic); 3. accelerator keys to work (ie. what is shown in the menus actually does something) When this bug gets revisited after the first release, we'll need to see what items remaining that need to be addressed.

my mistake. Correcting milestone back to previous one set. Netscape6 doesn't need this by nsbeta3 so leaving the nsbeta3 nomination off. This can be fixed at any time designated by timeless for Mozilla.

Checked with Mozilla trunk 2001071304 on W2K: 1. The correct URL for the spec is: http://www.mozilla.org/mailnews/specs/threepane/MailMenus.html 2. Mail mode Spec is met for all the accelerators of the Message menu in Mail and in News mode. However, some problems with the display of keyboard mnemonics and missing menu items exist. Mnemonics: Underlined character is in []brackets. Mail mode Spec Mozilla Comment ------------------------------------------------------------------------------------ Forward as->[I]nline Inl[i]ne Correct mnemonic, wrong display Forward as->[A]ttachment Att[a]chment Correct mnemonic, wrong display [E]dit Message as New Edit M[e]ssage as New Correct mnemonic, wrong display Add Sender to AB - Missing menu item (bug# 10860) Add All to AB - Missing menu item (bug# 10860) Mark->As Unread - Spec ok? Mark->[A]ll read Mark->All re[a]d Correct mnemonic, wrong display News mode Spec Mozilla Comment ------------------------------------------------------------------------------------ [R]eply to Sender Reply to Sende[r] Only Wording, display Forward as->[I]nline Inl[i]ne Correct mnemonic, wrong display Forward as->[A]ttachment Att[a]chment Correct mnemonic, wrong display [E]dit Message as New Edit M[e]ssage as New Correct mnemonic, wrong display Add Sender to AB - Missing menu item (bug# 10860) Add All to Address Book - Missing menu item (bug# 10860) Mark->As Unread - Spec ok? Mark->[A]ll read Mark->All re[a]d Correct mnemonic, wrong display [I]gnore Thread K Ignore Thread([K]) K double K, wrong mnemonic shown Is the character for the mnemonic that is actually underlined picked by the program or defined in one of the xul(?)-files?

it's picked by the program based on a heuristic which changes recently, i have patches/diffs lying around (and in bugs?) which should fix things you categorized as wrong display. I wondered about ignore thread. if there's no reason not to use I i'll fix that too.

Actually "Ignore thread" is quite messed up. Specs say: Use [I] as mnemonic (goes with ALT), and "K" as shortcut upon marked message. "K" as a shortcut may work (well, I really see no effect in using either ignore nor watch thread, but that may be just me being too lazy to find out what these commands are really supposed to do). [K] as mnemonic is alread in use by mar[k] one line above, and thus does not work. However, it still seems to produce the "(K)" after "ignore thread", that should not be displayed. [I], as in the spec, should be used as the mnemonic, unless the specs are outdated. And a fix to the heuristic would really be desirable. Maybe as first rule: If mnemonic corresponds to first character in menu item description, then underline this first character.

I'm just going to try to get a working build and get the mnemonic changes r=/sr=/committed. Changing the to special case the first character isn't something i'm interested in doing.

r=kerz

sspitzer: please sr=

time for 0.9.4 has run out. try for 0.9.5.. thanks

0.9.5 is out the door. bumping up the TM one notch

timeless: have the heuristics you mentioned in your post from 2001-07-16 ever been checked in? It appears to me that with the current logic the first match is picked that matches the case-setting in the dtd-file. Meaning: If the dtd-File looks like this ... <!ENTITY browserCmd.label "New Navigator Window"> <!ENTITY browserCmd.accesskey "n"> ..., the "n" in "Wi[n]dow" will be underlined, whereas if I change the second line to <!ENTITY browserCmd.accesskey "N"> then the N in [N]ew is underlined, which I guess we agree makes more sense and is more easily spotted. Two possible solutions: 1. Make it so that the first uppercase occurrence of the accesskey is picked for underline (some coding work). 2. Change the accesskey to uppercase in all the dtd-files (a lot of very boring work).

Andreas: The heuristics referred to were checked in as the fix for bug 41572, "Prefer matched case for Access keys". This would point to Option 2 as being the approved solution. Timeless has a probably stale patch to fix a bunch of access keys in bug 87792.

0.9.6 is long gone. -> 0.9.7

I change resolution to Invalid for originally logged bugs for 3pane Main Menus. Some design changes happened since that time and now expectation is different. Current status of Main Menus is addressed in the summary bug 75622, which tracks a few leftovers for Main Menu mnemonic issues in 3-pane window according to updated Spec. So original ones can be closed.

Verified.