22782 - Arrow/letter keys get to browser when menu is active

Status: VERIFIED FIXED

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

Description

[Luis Jose Lopez Lora]

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.

Comment 1

[Sean Richardson]

Congratulations, [e-mail], 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 [e-mail]  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.

Comment 2

[Sean Richardson]

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

Comment 3

[Kathleen :Brade]

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

Comment 4

[joki (gone)]

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

Comment 5

[joki (gone)]

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

Comment 6

[Sean Richardson]

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...

Comment 7

[Kevin McCluskey (gone)]

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

Comment 8

[Kevin McCluskey (gone)]

Marking it fixed.

Comment 9

[WD]

Verified