Overview Description: There is some kind of event handling problem with the keyboard. Many of them may be related to the way a keyboard event is dispatched throught the application. In general, if you use the keyboard to activate the menu object on the application, the keys you use still go to the browser object. Steps to Reproduce: 1) Check to see if you can do something with the keyboard on the browser. ---One way to do this is to see if you can move the browser window with the up/down cursor keys. You need a webpage that doesn't fit on one screen (bugzilla's 'enter bug' page is fine). If the cursor keys does not move the page, you can activate this behaviour by clicking and holding down the mouse button on a link on the page but release the mouse button out of the link (so you don't get transfered to the clicked link) ---Another way is to select an item on a combo list on a page (again, bugzilla's 'enter bug' page does the job, on the 'Component' list). Be sure that with the up/down cursor keys you can change to the next/previous element in the list. ---Another way is to place the carret on a textarea field of a form (again, bugzilla's 'enter bug', this time on this textarea: 'Description'). Normally, with the cursor keys you can move the carret. 2) Do something that transfers the focus on the application to some menu option outside the browser object by means of the keyboard. I generally use the File menu for this, using ALT-F, but other menu options will do. 3) Use the cursor keys or any letter keys to interact with the new focused menu element. Actual Results: You will see that the keys you type still hit the browser object. *Just by opening the menu, the carret is still visible and blinking. *If you use a letter alone with the menu, that letter selects an element in the menu and also selects an element on the combo list or gets inserted in a textarea field. *If you use the up/down/left/right cursor keys, the selected item on the menu changes, but also the position of the browser window (you still can move it forward or backward), the selected item on a list, or the carret position on a textarea field (all of the applicable elements always get executed). On Build 1999122023 (M12), you could select every item on the menu, but on 1999122808 the cursor keys only selected the first and last elements in it. Expected Results: Only the menu should get the corresponding keyboard events, and not the browser behind it. Carret should be disabled also. Build Date & Platform Bug Found: 1999122808 on Win98 Additional Builds and Platforms Tested On: 1999122023 on Win98 Additional Information: When you transfer the focus of the application to some other object, keyboard events should only hit the current focused object. The event needs to be set as 'dispatched', or the browser needs to be marked as 'non active', so it does not receive keyboard events. The menu should work as stated.

Congratulations, llopez@spin.com.mx, for finding the general case and writing it up well the first time! The fundamental problem is that it is possible to have keypresses go to both the Menu system and elsewhere (URL bar, text input boxes, textareas, other form controls). Obviously, once focus is given to the menu system, keypresses should go only to the menus, and not to both the menus and to whatever had focus immediately before. See the comment under "Additional Comments From sidr@albedo.net 1999-12-13" in bug 15048 "ALT-Tabbing away from Mozilla creates spurious ALT events" for the converse case, where after moving focus to a text input or textarea, keypresses still affect the menu system as well as appearing where the caret is. Marking Bug 18844 "Typing in menu after editbox sends keypress to both" as a DUP of this one since this report describes that problem as well as similar problems with other form controls, in one coherent account. The issue with cursor keys not working properly in menus since M12 is a distinct problem unrelated to the main issue here. I'm not sure if there is a bug reported for that already or not.

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

changing summary from "Cursor" to "Arrow" since that is what the author of this bug appears to have intended to use.

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

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

Checking up on this for bug 18598, "menus take focus on "alt," then behave in a non-standard way", this problem does not seem to be happening anymore. With luck, once it is fixed, this will continue working properly...

I'm not seeing any problems with events going to both the content area and menu with 2/29/2000 build on WINNT.

Marking it fixed.

Verified