Closed Bug 24335 Opened 25 years ago Closed 25 years ago

Keypresses continue to get to menu after focus moved away

Categories

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

x86
Windows NT
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: sidr, Assigned: saari)

Details

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.
This bug has been filed primarily for historical accuracy. saari@netscape.com 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.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Yes, this has been fixed as a part of the menu keyboard navigation fixes.
Keywords: verifyme
Verified fixed.
Status: RESOLVED → VERIFIED
Keywords: verifyme
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.