498725 - Holding <alt> key while pressing certain access keys within composition's main menus, menu commands not executed because access keys from unfocused UI elements trigger instead (unfocused window-level access keys steal focus from menu-level)

Status: NEW

(Thunderbird :: Message Compose Window, defect)

Description

[Matěj Cepl]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; cs-CZ; rv:1.9.1b4) Gecko/20090427 Fedora/3.5-0.20.beta4.fc11 Firefox/3.5b4
Build Identifier: thunderbird-3.0-2.4.b3pre.hg.6a6386c16e98.fc11.x86_64

When browsing through menus with Alt+<letter> (Alt is being pressed not only for pulling down the first menu, but continually even for selection of submenus and items in menus), weird things happen as shown below.

User documentation is rather sparse on this point (as on many others), but it seems to me that pressing of Alt+<letter> in menu should be an equivalent of just pressing <letter>.

====================
Issue 1, Compose Window -- Insert Rows to a exist Table

Steps to Reproduce:
1.   'Ctrl + N' to open a new message window and Insert a table('Insert >
Table')
2.    Put the cursor into any cell of this table.
3.    Insert a row in this table by keyboard operation,("Format  > Table >
Insert > Row Above ' )

Actual results:
if do all these operates by keyboard, "Format  > Table > Insert > Row Above '
will not insert a line above the current line, but set the focus to the
mail-address area.

Expected results:
It should be insert a new row correct.

Additional info:

====================
Issue 2, Compose Window -- Select elements from current table

Steps to Reproduce:
1.   'Ctrl + N' to open a new message window and Insert a table('Insert >
Table')
2.    Put the cursor into any cell of this table.
3.    Select this table by keyboard operation,("Format  > Table > Select >
Table ' )

Actual results:
Operates by keyboard, it will select the whole table, but it will change the
focus to the "Subject" area.  uper-case "S" is for the table, and little case
"s" is for the email "Subject" area.

Expected results:
It should still keep the focus in the content area.

Additional info:

====================
Issue 3, Compose Window -- Delete elements from current table

Steps to Reproduce:
1.   'Ctrl + N' to open a new message window and Insert a table('Insert >
Table')
2.    Put the cursor into any cell of this table.
3.    Delete a row in this table by keyboard operation,("Format  > Table >
Delete > Row(s) ' )

Actual results:
Operates by keyboard, when deleting row, only upper case "R" will work. Others
works ok.

Expected results:
If it's a upper case 'R', it's better specify it by some lable.

Additional info:

====================
Issue 4, Compose Window -- Split cell

Steps to Reproduce:
1.   'Ctrl + N' to open a new message window and Insert a table('Insert >
Table')
2.    Put the cursor into any cell of this table.
3.    Split a row in this table by keyboard operation,("Format  > Table > Split
Cell ' )

Actual results:
Only joined cells can split 

Expected results:
sometimes, the user will expect split normal cell.

Additional info:

====================
Issue 5, Compose Window -- Create table from selection

Steps to Reproduce:
1.   'Ctrl + N' to open a new message window and Insert a table('Insert >
Table')
2.    Select the table.
3.    Create a new table from Selection,("Format  > Table > Create table from
selection ' )

Actual results:
by keyboard operation, Uper case "r" needed, but the label shows a small case
"r"


Reproducible: Always

Steps to Reproduce:
1.see above
2.
3.
Actual Results:  
Pressing Alt+<letter> in submenus and menus is not the same as pressing just <letter>.

Expected Results:  
It should be

Comment 1

[Matěj Cepl]

(originally filed as https://bugzilla.redhat.com/show_bug.cgi?id=506082)

Comment 2

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Wayne, does this occur on Windows too?

Comment 3

[Wayne Mery (:wsmwk)]

(In reply to comment #2)
> Wayne, does this occur on Windows too?

passing the torch to JoeS. I'm really pressed for time the next few days plus don't do HTML mail almost ever.  Ron K may also be able to test

Comment 4

[Joe Sabash [:JoeS1]]

Well, there are "mousers" and there are "keyboarders", I'm a mouse guy. 
So the steps tp reproduce were not obvious to me.

For case 1, new str:
 Open a compose window
 Insert a table
 Position the cursor in one of the cells

Hold down the alt key and key in:
o b i r

Notice that the last key entry "r" does not yield the desired result.
Also notice that stepping through the menu selection, you succeed in the i selection, even though it is capitalized, yet if you repeat the test, and hold down shift, when depressing the last "r" the menu selection works.

So we have an inconsistency on when shift must be used.

There are probably many more inconsistencies like this, but this is one.
Confirmed.

Comment 5

[Ronald Killmer]

For those who use the keyboard the accidental activation of the [Caps Lock]
kills normal keyboard activation of some menued commands. The 'n' key nav fails
since 'N' is not equivalent. Yet a look at the Go menu shows 'N' as the key for
Next Unread.

This indicates that key assignments need an in depth review. It's not just the
[Alt]+[x] cases where inconsistencies exist.  This entire issue has
Accessibility and L10N implications. I feel that menu notations should match
the key used caseing, i.e. upper/lower.

Comment 6

[Wayne Mery (:wsmwk)]

for historical references:
bug 158679 and friends.
http://tinyurl.com/lawds2

Comment 7

[Wayne Mery (:wsmwk)]

http://tinyurl.com/lawds2 =  https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&product=MailNews+Core&product=Thunderbird&bug_severity=major&bug_severity=normal&bug_severity=minor&chfieldto=Now&field0-0-0=short_desc&type0-0-0=allwordssubstr&value0-0-0=Caps+Lock&field0-0-1=short_desc&type0-0-1=allwordssubstr&value0-0-1=upper+case&field0-0-2=short_desc&type0-0-2=allwordssubstr&value0-0-2=capiltal+letter

Comment 8

[Ronald Killmer]

A good point was made in Bug 158679 that Menu key labels by convention are upper case. So I withdraw my personal opinion from Comment #5.

Another comment there suggested use of keyboard position codes, since use of an Alt keyboard mapping can break Alpha coded keystroke detection. That usage case suggests the installed App is one localaization and the user has swapped to another language.

Comment 9

[Thomas D. (:thomas8)]

Let's try to make this bug actionable.
I'll first go through all issues as reported, then we can summarize and conflate identical cases.

(In reply to Matěj Cepl from comment #0)
> When browsing through menus with Alt+<letter> (Alt is being pressed not only
> for pulling down the first menu, but continually even for selection of
> submenus and items in menus), weird things happen as shown below.
> 
> User documentation is rather sparse on this point (as on many others), but
> it seems to me that pressing of Alt+<letter> in menu should be an equivalent
> of just pressing <letter>.

That's a reasonable expectation as it works for most cases except those where we interfere.

> ====================
> Issue 1, Compose Window -- Insert Rows to a exist Table
> 
> Steps to Reproduce:
> 1.   'Ctrl + N' to open a new message window and Insert a table('Insert >
> Table')
> 2.    Put the cursor into any cell of this table.
> 3.    Insert a row in this table by keyboard operation,("Format  > Table >
> Insert > Row Above ' )

Hold alt while subsequently pressing the following character keys:
<alt> + o,i,b,r

Actual result:
Although focus is clearly in the menu and not in the underlying composition window, we catch
<alt> + r --> F_r_om (sets focus to from)


Expected result:
Focus respect.
With focus in menu, we must stop catching keypress event for <alt>+r in main window.
In this case, insert row.


> ====================
> Issue 2, Compose Window -- Select elements from current table
> 
> Steps to Reproduce:
> 1.   'Ctrl + N' to open a new message window and Insert a table('Insert >
> Table')
> 2.    Put the cursor into any cell of this table.
> 3.    Select this table by keyboard operation,("Format  > Table > Select >
> Table ' )

(hold alt continuously)
<alt> + o,b,s,t

Actual: 
Although focus is clearly in the menu and not in the underlying composition window, we catch
<alt> + s --> _S_ubject (focus subject row).
Weirdly, user can still continue in the menu up to <alt> + t, but then we just ignore that and do our own thing.

Expected:
Respect menu focus: Select Table, don't catch <alt>+s for subject.

> ====================
> Issue 3, Compose Window -- Delete elements from current table
> 
> Steps to Reproduce:
> 1.   'Ctrl + N' to open a new message window and Insert a table('Insert >
> Table')
> 2.    Put the cursor into any cell of this table.
> 3.    Delete a row in this table by keyboard operation,("Format  > Table >
> Delete > Row(s) ' )

(hold alt continuously)
<alt> + o,b,d,r

Actual:
Focus in menu, but we don't delete row. Instead, we keep catching
<alt> + r --> F_r_om (focus from field)

Expected:
Respect menu focus: Delete row, don't catch <alt>+r for From.

> ====================
> Issue 4, Compose Window -- Split cell
> 
> Steps to Reproduce:
> 1.   'Ctrl + N' to open a new message window and Insert a table('Insert >
> Table')
> 2.    Put the cursor into any cell of this table.
> 3.    Split a row in this table by keyboard operation,("Format  > Table >
> Split Cell ' )

This does not depend on keyboard operation, so it's misplaced here.

> Actual results:
> Only joined cells can split 

Yeah, that's unexpected. This is totally different from the other issues; needs a new bug if it's not filed yet. Note that fixing editor bugs of that sort is hard to get these days.

> Expected results:
> sometimes, the user will expect split normal cell.

Indeed, that's a totally reasonable and useful expectation.

> ====================
> Issue 5, Compose Window -- Create table from selection
> 
> Steps to Reproduce:
> 1.   'Ctrl + N' to open a new message window and Insert a table('Insert >
> Table')

No, for this one you start out with simple text:
1. type plain text:
foo1,bar1
foo2,bar2

> 2.    Select the table.
2. Select the plaintext "table"

> 3.    Create a new table from Selection,("Format  > Table > Create table from
> selection ' )

3. (hold alt continuously)
<alt> + o,b,r

Actual:
Focus in menu, but we don't create table. Instead, we keep catching
<alt> + r --> F_r_om (focus from field)

Expected: 
Respect menu focus: Create table from selection, don't catch <alt>+r for From.

> Actual Results:  
> Pressing Alt+<letter> in submenus and menus is not the same as pressing just
> <letter>.

Yes, and that's wrong and unexpected. At least starting out with <alt> + o, then just pressing the characters without holding <alt> will do the trick correctly.

> Expected Results:  
> It should be

For all of the above (except 4), the expected result is:
Respect focus in menu and execute menu commands accordingly.
With focus in menu, don't catch <alt> + access keypress for underlying main UI.

Comment 10

[Thomas D. (:thomas8)]

New Description and STR:

In composition window, we catch some special access keys, iirc using onkeypress event, e.g. <alt>+r --> Focus F_r_om field. This conflicts with menu access keys when user keeps holding <alt> key while pressing second-level menu access keys, so e.g. <alt>+r with focus on menu can occur, which is then stolen by the window-level listeners.

STR:
- Composition, with cursor in existing table...
- Hold <alt> key continually while using keyboard access keys for menus:
1) <alt> + o,b,i,r (Format > Table > Insert > Row Above)
OR
2) <alt> + o,b,s,t (Format > Table > Select > Table)

Variations of 1) as reported in comment 0:
3) <alt> + o,b,d,r (Format > Table > Delete > Row)
- composition, with plaintext 'table' selected:
> foo1,bar1
> foo2,bar2
5) <alt> + o,b,r (Format > Table > Create Table from Selection)

Actual result:
Although focus is clearly in menu, if user holds <alt> while pressing subsequent access keys, expected Menu command is not executed.
Instead, we catch <alt> + access key keypress event in underlying window and execute that:
1)3)5) <alt> + r --> Focus F_r_om field
2) <alt> + s --> Focus _S_ubject field
<alt> + c --> Focus atta_c_hment panel if shown (attach one local file)
<alt> + a --> _A_dd attachment from automagical attachment reminder bar (type "attachment" in body)
<alt> + l --> Remind me _L_ater from automagical attachment reminder bar
Meaning that depending on circumstances, all of these access keys (r,s,c,a,l) will be ignored in menus if user keeps holding <alt>.

Expected result:
Respect menu focus. Don't steal focus from underlying UI.
I.e. don't listen for the following keypress events while focus is in menu:
<alt> + either of {r, s, c, a, l}
Instead, just execute the expected commands:
1) Insert Row Above
2) Select Table
3) Delete Row
5) Create Table from selection.

Comment 11

[Thomas D. (:thomas8)]

What I don't understand: When the menu has focus, why do those keypress events even get propagated to the window level? They should just be consumed on the menu and then stop propagation. Or maybe it's the other way round, and keypress first arrives on window-level? Need to check out event bubbling or so, and control that correctly.

Comment 12

[Thomas D. (:thomas8)]

The same is likely to happen in the main 3pane window, we have certain infobars which have access keys which might potentially conflict with their twins from inside main menus.

Uppercase/lowercase access keys can be ignored I think, that's not part of this bug, according to the design of the window-level listeners they will not catch certain variations. In that respect, Shift+access key is not the same as CapsLock + access key.

Comment 13

[Thomas D. (:thomas8)]

Event capture phase, target phase, and bubbling phase nicely described here:
https://www.w3.org/TR/DOM-Level-3-Events/#dom-event-architecture

Comment 14

[Thomas D. (:thomas8)]

Looks like contrary to my assumption in comment 10, we're not using onkeypress event for the access keys on those non-menu elements in the main UI, because they have regular accesskey="..." properties. Which makes this even more mysterious to me. How can access keys of mutually exclusive UI elements conflict? When the menu has focus, how come access keys from unfocused main UI are still processed?

https://dxr.mozilla.org/comm-central/source/mail/components/compose/content/messengercompose.xul#921
> 920 <label id="identityLabel" value="&fromAddr.label;"
> 921        accesskey="&fromAddr.accesskey;" control="msgIdentity"/>

https://dxr.mozilla.org/comm-central/source/mail/locales/en-US/chrome/messenger/messengercompose/messengercompose.dtd#229
> 229 <!ENTITY fromAddr.label "From:">
> 230 <!ENTITY fromAddr.accesskey "r">

In the main menu, it's also regular access keys:
https://dxr.mozilla.org/comm-central/search?q=rowabove+ext%3Axul&redirect=false

https://dxr.mozilla.org/comm-central/source/editor/ui/composer/content/EditorContextMenuOverlay.xul#61

> 61 <menuitem label="&tableRowAbove.label;"
> 62 accesskey="&tableRowAbove.accesskey;"
> 63 command="cmd_InsertRowAbove"/>

https://dxr.mozilla.org/comm-central/source/editor/ui/composer/content/editorOverlay.xul#261

> 261 <command id="cmd_InsertRowAbove"      oncommand="goDoCommand('cmd_InsertRowAbove')"/>
> 827 <menuitem id="menu_tableRowAbove"
> 828 label="&tableRowAbove.label;"
> 829 accesskey="&tableRowAbove.accesskey;"
> 830 command="cmd_InsertRowAbove"/>

https://dxr.mozilla.org/comm-central/source/mail/components/compose/content/editorOverlay.xul#190

> 190 <command id="cmd_InsertRowAbove"      oncommand="goDoCommand('cmd_InsertRowAbove')"/>
> 692 <menuitem id="menu_tableRowAbove"
> 693 label="&tableRowAbove.label;"
> 694 accesskey="&tableRowAbove.accesskey;"
> 695 observes="cmd_InsertRowAbove"/>

https://dxr.mozilla.org/comm-central/source/editor/ui/locales/en-US/chrome/composer/editorOverlay.dtd#245

> 245 <!ENTITY tableRowAbove.label "Row Above">
> 246 <!ENTITY tableRowAbove.accesskey "R">

Comment 15

[Thomas D. (:thomas8)]

Mystery doesn't end there:

When menu is open, certain keys are ignored while others are unexpectedly intercepted by the main editor UI.

In composition:
1) Type "foobar"
2) place cursor in the middle between "foo" and "bar"
3) <alt> + o, then y --> Invalid access key, beeps; correctly does NOT insert "y" into text
4) <tab> --> unexpectedly closes the menu and inserts a tab between foo and bar! (would expect either beep or moving focus between available options; in Windows notepad, it's beep).

As another example, after opening a menu:
<ctrl> + <enter> will open/confirm the currently selected menu; i.e. here <modifier> + <enter> is NOT propagated to the unfocused main UI.

So why does it get wrongly propagated to unfocused elements in this case?
<modifier> + <character>
<alt> + r

Comment 16

[Thomas D. (:thomas8)]

(In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment #15)

> As another example, after opening a menu:
> <ctrl> + <enter> will open/confirm the currently selected menu; i.e. here
> <modifier> + <enter> is NOT propagated to the unfocused main UI.

Note that <ctrl> + <enter> is a valid shortcut key from unfocused main UI to "Send message".
 
> So why does it get wrongly propagated to unfocused elements in this case?
> <modifier> + <character>
> <alt> + r

Per this bug, this will unexpectedly close the menu and focus F_r_om field instead of triggering menu commands like "[Insert] _R_ow above".

Comment 17

[Thomas D. (:thomas8)]

I'm not sure why users would want to hold their [Alt] key all the way while hitting access keys for menu navigation, but I guess it's a legitimate legacy behaviour and it normally works both for XUL and windows applications like Notepad or Word 2010. Btw Word 2010 has a pretty nice visual and responsive implementation of access keys.

XUL bug 225172, comment 0 mentions that ALT modifier is allowed within menus:
> Pressing Ctrl+C with a menu (or context menu) open activates the item with
> mnemonic C.  The only modifier menus should allow is Alt (and maybe Shift).

Comment 19

[Anje]

Using Windows Vista and Thunderbird version 45.3.0
In 'Write' window.
Enable 'Contacts Sidebar'
Focus is in the main composing text area, so all menu items on 'Menu Bar' are available (not greyed out).

Task: want to select 'Format' on the 'Menu Bar' using keys.
use 'Alt' + 'O'

Result: 
On 'Menu Bar', 'Insert' and 'Format' instantly become greyed out.
Text cursor focus moves away from the text composing area.
Focus has moved to 'Search For' textbox in the 'Contacts Sidebar'.

Close 'Contacts Sidebar'
Focus in composing text area.
use 'Alt' + 'O'
Result:
Menu Bar 'Format' option opens to display drop down list.

Conclusion: Works perfectly ok providing the 'Contacts Sidebar' is closed.

Also tested in Safe mode - no change to the above.
Do you want me to add this a new bug or is it part of this bug?

Comment 20

[Wayne Mery (:wsmwk)]

FWIW, xref firefox bug 724338, which I had closed invalid