24335 - Keypresses continue to get to menu after focus moved away

Status: VERIFIED FIXED

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

Description

[Sean Richardson]

This bug has been split off from bug 15048, "ALT-Tabbing away from Mozilla
creates spurious ALT events", FIXED, for independent testing and verification
-- it looks fixed now too.

Overview:
Clicking inside an edit field does not take focus away from the menubar as it
gives focus to the edit field. If the menubar has focus just before  *any* edit
field (Location bar, <input>, <textarea>, and just about any UI element in
Message Compose or Composer) is given focus, typing in it will both add
characters to the edit field *and* activate, in turn, any menu or submenu for
which a typed character is an accelerator key that is valid in the current
state of the menu expansion ("e","f" does Edit>Preferences, while "f","e" does
File>New).

Steps to reproduce:
1. Press-and-release the ALT key once or twice to give focus to the menubar
   (visible highlighting of File menu without it being raised).
2. Click anywhere that text can be entered.
3. Type some text including "f", "e", or another character that is a primary
   menu accelerator key.

Actual Results:
A. After step 2, the menubar still shows that it has focus.
B. As above: typed keys affect both the edit field and the menubar.


Expected Results:
A. After step 2, the edit field has focus and the menubar does not.
B. Text typed into the edit field in step 3 does not affect the menubar.

Tested with:
2000-01-18-08-M13 nightly binary on Windows NT 4.0sp3 (bug gone)
1999-12-12-08-M12 nightly binary on Windows NT 4.0sp3 (bug present)

Additional Information:
The second part of this bug looks like the converse of bug 22782, "Arrow/letter
keys get to browser when menu is active" -- where if focus is shifted from
a browser object to the menu system, key events go both to the menu system and
to the object that previously had focus.

Comment 1

[Sean Richardson]

This bug has been filed primarily for historical accuracy. [e-mail]
can say if this was fixed as part of fixing bug 15048. It is also possible
that this was fixed by other work on focus issues, and this may be a DUP.

Whatever the proper resolution, unlike bug 22782, this does not appear to be a
problem anymore. Sorry for cluttering up 15048 with a second issue.

Comment 2

[saari (gone)]

Yes, this has been fixed as a part of the menu keyboard navigation fixes.

Comment 3

[John Unruh]

Verified fixed.