Closed Bug 206917 Opened 22 years ago Closed 22 years ago

unable to use down/up arrow keys to choose selection in XUL droplists

Categories

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

PowerPC
macOS
defect
Not set
major

Tracking

()

VERIFIED FIXED
mozilla1.4final

People

(Reporter: bugzilla, Assigned: bryner)

References

Details

(Keywords: platform-parity, regression, Whiteboard: [adt1][fixed on branch and trunk])

Attachments

(1 file)

found using 2003.05.23.06 comm bits on Mac OS X 10.2.6. appears to be mac-specific, as i cannot repro on today's linux build. this crept in today's build --it wasn't a problem with yesterday's (2003.05.22.08). i thought this might be a regression from the fix from bug 184549, but kathy says that that might've just uncovered an older bug that was already there. reassign as needed. 1. open a XUL dialog or sheet that contains a droplist (dropmenu). eg, Open web Location (cmd-shift-L) or the Navigator (or Font, Languages, etc) pref panel. 2. use the tab key to move focus to the droplist (it should get a focus ring). 3. hit the down arrow key to expand the droplist --this actually works. 4. hit the down (or up) arrow key to move the highlight (selection) in the droplist. results: the selection doesn't change. in fact, hitting the escape key doesn't collapse the droplist either. strangely, i can use the tab key to move to the other widgets in the dialog/sheet.
unfortunately I don't have time to debug this much more right now. I did find out that the mac widget code is dispatching both a key down and a keypress event. nsMenuListener.cpp is getting the keydown event but not getting the keypress event.
occurs throughout the app wherever there's a xul droplist: mailnews 3pane (View), html mail compose, editor window. also occurs if i focus and expand a droplist using the mouse.
Severity: normal → major
Flags: blocking1.4?
(side note: not theme specific, as it occurs in both modern and classic.)
aaron, any ideas what might be going on here?
Attached patch patchSplinter Review
Ok, the problem turns out to be that we're reusing event structs for two types of events (keydown, keypress). We went through this on all of the other toolkits, I'm surprised Mac hasn't had a problem yet. (The problem involves the system event group flag staying set or something like that)
Attachment #124324 - Flags: superreview?(sfraser)
Attachment #124324 - Flags: review?(brade)
Comment on attachment 124324 [details] [diff] [review] patch I dreamed about this bug last night and guessed it was the same thing your patch does. The difference in my patch would've been that I just reinitialized the event without declaring a 2nd one (for keydown/keypress). :-) r=brade
Attachment #124324 - Flags: review?(brade) → review+
Comment on attachment 124324 [details] [diff] [review] patch >+ nsKeyEvent keyUpEvent; >+ InitializeKeyEvent(keyUpEvent,aOSEvent,focusedWidget,NS_KEY_UP); Since you'll get blamed for this line, please add spaces after the commas. >+ case keyDown: >+ { >+ nsKeyEvent keyDownEvent, keyPressEvent; >+ InitializeKeyEvent(keyDownEvent,aOSEvent,focusedWidget,NS_KEY_DOWN); And here >+ InitializeKeyEvent(keyPressEvent,aOSEvent,focusedWidget,NS_KEY_PRESS); Ditto. >+ nsKeyEvent keyPressEvent; >+ InitializeKeyEvent(keyPressEvent,aOSEvent,focusedWidget,NS_KEY_PRESS); Predictably ditto. I wish bug fixes came to me in dreams!
Attachment #124324 - Flags: superreview?(sfraser) → superreview+
Comment on attachment 124324 [details] [diff] [review] patch let's get this on the trunk first, and if all goes well, take it for the 1.4 branch, assuming it does fix that 1.4 blocker, bug #207291
Attachment #124324 - Flags: approval1.4?
checked in on the trunk.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Comment on attachment 124324 [details] [diff] [review] patch a=asa (on behalf of drivers) for checkin to the 1.4 branch.
Attachment #124324 - Flags: approval1.4? → approval1.4+
[plussing to get onto my query radar]
Flags: blocking1.4? → blocking1.4+
adt: nsbeta1+/adt1 Please make sure this lands on the 1.4 branch resolving it by adding the fixed1.4 keyword. Thanks.
Keywords: nsbeta1nsbeta1+
Whiteboard: [adt1]
Keywords: fixed1.4
Whiteboard: [adt1] → [adt1][fixed on branch and trunk]
Target Milestone: --- → mozilla1.4final
vrfy'd fixed with both trunk and 1.4 branch builds (2003.05.29 commercial).
Status: RESOLVED → VERIFIED
Keywords: fixed1.4verified1.4
Component: Keyboard: Navigation → User events and focus handling
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: