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)

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

Mass update: changing qacontact to ckritzer@netscape.com

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

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

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

moving nomination to keyword field. -> saari

CCing akkana, whom I believe just fixed all of this

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.

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

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.

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?

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

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.

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.

Fixed now.

Updating QA Contact.

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

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

QA contact updated

verifying