40071 - accesskey doesn't block menus

Status: VERIFIED FIXED

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

Description

[Jesse Ruderman]

When the content area has focus, accesskey events trigger buttons correctly, 
but menus still drop down (so pressing alt-d at the url, for example, disables 
the form elements and also drops down the debug menu)

Comment 1

[Jesse Ruderman]

Attachment: test case

Comment 2

[Antti Näyhä]

I see this in Linux build 2000-05-22-08, too.  Changing Platform/OS to All/All.

Comment 3

[ckritzer (gone)]

Mass update:  changing qacontact to [e-mail]

Comment 4

[Peter Trudelle]

I'm seeing correct behavior using today's M18 verification build on Linux. 
resolving as wfm.

Comment 5

[Jesse Ruderman]

still seems broken to me.  reopening.
i'm running 2000 081508 on win98, and tried both the modern and classic skins.

Comment 6

[Gervase Markham [:gerv]]

Nominating for nsbeta3 - accesskeys are pretty useless without this. Also seen 
in WinNT4 20000819.

Make sure you view this test case in a build with a QA menu :-)

Gerv

Comment 7

[Peter Trudelle]

moving nomination to keyword field. -> saari

Comment 8

[saari (gone)]

CCing akkana, whom I believe just fixed all of this

Comment 9

[Akkana Peck]

I'm not sure whether I fixed it or not ... 'fraid I don't understand the bug or
exactly what the correct behavior should be.  And my fix should only change
Linux behavior, if I did it right, so if this bug is truly XP as it says it is,
then my fix yesterday probably won't change it.

Comment 10

[Peter Trudelle]

need info: I'm not sure how to reproduce this, could someone please add exact
steps, expected/obseved behavior?
cc jrgm. 

Comment 11

[Jesse Ruderman]

load http://bugzilla.mozilla.org/showattachment.cgi?attach_id=8919 and press 
alt-e.  we expect the "enable everything" button to be activated and nothing 
else, but the edit menu drops down in addition to the button being activated.

Comment 12

[Akkana Peck]

Okay, I see.  And I do see the behavior described.  I'm not sure how this is
supposed to work, though: I take it the button is supposed to be activated and
nothing else?  So maybe the event isn't being cancelled properly in the button
code, or the menu code needs to be checking whether the event was cancelled and
isn't checking properly?

Comment 13

[Peter Trudelle]

reassigning to pinkerton as nsbeta3+, p3 for m18.  cc joki & saari.

Comment 14

[Mike Pinkerton (not reading bugmail)]

tell me if this is correct:

when I get the key event in the menu code, I need to check if preventDefault has
been called on it? If so, i ignore the event?

I'm new to all this default processing mumbo-jumbo.

Comment 15

[Mike Pinkerton (not reading bugmail)]

ok, i'm landing changes that make the menu listeners check for PreventDefault 
being set on the dom event, but apparantly, it's not being set, and I'm not sure 
where accesskeys are handled. Pushing bug back to gecko for them to do the right 
thing.

Comment 16

[joki (gone)]

Fixed now.

Comment 17

[Loco]

Updating QA Contact.

Comment 18

[Antti Näyhä]

Verifying that this now works as expected on Win32 (build 2000092508).

Comment 19

[Hixie (not reading bugmail)]

Reassigning QA Contact for all open and unverified bugs previously under Lorca's
care to Gerardo as per phone conversation this morning.

Comment 20

[Madhur Bhatia]

QA contact updated

Comment 21

[:deanis74]

verifying