Closed Bug 40071 Opened 25 years ago Closed 24 years ago

accesskey doesn't block menus

Categories

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

defect

Tracking

()

VERIFIED FIXED

People

(Reporter: jruderman, Assigned: joki)

References

()

Details

(Whiteboard: [nsbeta3+])

Attachments

(1 file)

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)
Attached file test case
Blocks: 39985
I see this in Linux build 2000-05-22-08, too.  Changing Platform/OS to All/All.
OS: Windows 98 → All
Hardware: PC → All
Mass update:  changing qacontact to ckritzer@netscape.com
QA Contact: janc → ckritzer
I'm seeing correct behavior using today's M18 verification build on Linux. 
resolving as wfm.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
still seems broken to me.  reopening.
i'm running 2000 081508 on win98, and tried both the modern and classic skins.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
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
Whiteboard: nsbeta3
moving nomination to keyword field. -> saari
Assignee: hyatt → saari
Status: REOPENED → NEW
Keywords: nsbeta3
Whiteboard: nsbeta3
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. 
Whiteboard: [need info]
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.
Assignee: saari → pinkerton
Whiteboard: [need info] → [nsbeta3+]
Target Milestone: --- → M18
Status: NEW → ASSIGNED
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.
Assignee: pinkerton → joki
Status: ASSIGNED → NEW
Fixed now.
Status: NEW → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → FIXED
Updating QA Contact.
QA Contact: ckritzer → lorca
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: lorca → gerardok
QA contact updated
QA Contact: gerardok → madhur
verifying
Status: RESOLVED → VERIFIED
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: