17749 - Menu activated on keypress after ALT-TAB to Mozilla App

Status: VERIFIED DUPLICATE of bug 15048

(Core :: DOM: UI Events & Focus Handling, defect, P3)

Description

[Sean Richardson]

Summary:
The ALT key appears to be sticky: if it is pressed and released before
pressing an alpha key, a menu can be activated as if what was typed was
ALT+key rather than ALT, key.

Steps to reproduce:
1. Click in a <textarea>, <input>, or in the location bar to give it focus.
2. Press and release the ALT key.
3. Press "e" for edit or any other menu ALT-hotkey.

Actual result:
The menu corresponding to the unmodified alphabetic key is activated
and the character is entered into the <textarea>, <input>, or location bar.

Expected result:
The character is entered into the <textarea>, <input>, or location bar.

Tested with:
Windows 95, mozilla.exe, 1999-10-31-08-M11 nightly binary.

Speculation:
This seems to explain bug 17683 as well as the following more complex case.

Additional Information:
No, the Windows Accessiblity "StickyKeys" option is not enabled. This is
not affecting any other apps.

Simplified this one as it was written. Original report follows.

-----

Summary:
While typing into text <INPUT>s, <TEXTAREA>s, or the location bar,
one or more menus may appear when plain ascii text is typed,
if ALT-TAB.

Steps to Reproduce:
1.  Use ALT-TAB to switch from this page (or any other with a textarea).
2.  Use ALT-TAB to switch back to this page.
3.  Click in the "Additional Comments" <TEXTAREA> to give it focus.
4.  Type any letter that is used with ALT to activate a menu (e.g, e for edit)
    without holding doen the ALT key.
5.  Repeat steps 1 and 2.
6.  Click in the "Status Whiteboard" INPUT to give it focus.
7.  Type any letter that is used with ALT to activate a menu (e.g, f for file).
    without holding doen the ALT key.
8.  Repeat steps 1 and 2.
9.  Click in the location bar to give it focus.
10. Type any letter that is used with ALT to activate a menu (e.g, h for help).
    without holding doen the ALT key.

Actual Result:
In steps 4, 7 & 10, the menu whose name begins with the letter
typed will activate. The character will also appear in the <TEXTAREA>,
<INPUT>, or location bar repectively.

Expected Result:
The character will appear in the <TEXTAREA>, <INPUT>, or location bar
repectively, for steps 4, 7 & 10, and no menu will be activated.

Tested with:
Windows 95, mozilla.exe, 1999-10-31-08-M11 nightly binary.

Additional information:
The same bug has shown itself with every build I've tried, at least since M10.

Speculation:
The cause of this bug and the cause of bug 17683 may have the same root:
somehow Mozilla does not notice that the ALT key is no longer being held down!
Could it be as simple as that?

Comment 1

[Sean Richardson]

If the cause of bug 17683 is, as [e-mail] suggests, code
that is still listening to KeyDown instead of KeyPressed, this
bug is almost certainly a DUP of 17683.

Comment 2

[Sean Richardson]

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

Comment 3

[rickg]

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

Comment 4

[Richard Zach]

I get the same thing on Linux.  Pressing and releasing the ALT key activates the
menu, the keyboard focus stays in the location bar, say.  ALT-TAbbing to
activate the browser window, click in location bar, type F pulls down the file
menu and enters F into the location bar.  (1999.11.28.08 Linux build on RH 6.0
running Gnome)

Comment 5

[joki (gone)]

Hey Chris, since you currently own menus and sorta own focus this is totally
you.  Have fun.

Comment 6

[Sean Richardson]

Doh. Pressing and releasing the ALT key *should* switch focus to the menus,
at least on Win32 - it does on all other Apps. The only reason I can think
of that I missed this is bug 19301 - without the immediate, bold, highlighting
of the File menu upon ALT press-and-release, it didn't *look* like the same
(annoying when done accidentally) behaviour.

On the other hand, keypresses after arriving at a Mozilla App by using ALT-TAB
*should not* be interpreted as if ALT had been pressed and released - that
event was handled by Windows! (Or Xwindows, see the first 11/29/99 comment)

Changing summary to reflect this.
Also, given the above and the existing fix for bug 17683, this bug is obviously
independent of bug 17683.

Comment 7

[Sean Richardson]

This is clearly a duplicate of bug 15048; read the 12/04/99 comment to
see why.


*** This bug has been marked as a duplicate of 15048 ***

Comment 8

[Joseph Elwell]

[bugday] verified, although I didn't see any 12-04 comments on the other bug. :)