Closed
Bug 206917
Opened 21 years ago
Closed 21 years ago
unable to use down/up arrow keys to choose selection in XUL droplists
Categories
(Core :: DOM: UI Events & Focus Handling, defect)
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)
6.40 KB,
patch
|
Brade
:
review+
sfraser_bugs
:
superreview+
asa
:
approval1.4+
|
Details | Diff | Splinter Review |
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.
Comment 1•21 years ago
|
||
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.
Reporter | ||
Comment 2•21 years ago
|
||
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?
Reporter | ||
Comment 3•21 years ago
|
||
(side note: not theme specific, as it occurs in both modern and classic.)
Reporter | ||
Comment 4•21 years ago
|
||
aaron, any ideas what might be going on here?
Assignee | ||
Comment 5•21 years ago
|
||
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)
Assignee | ||
Updated•21 years ago
|
Attachment #124324 -
Flags: superreview?(sfraser)
Attachment #124324 -
Flags: review?(brade)
Comment 6•21 years ago
|
||
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 7•21 years ago
|
||
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 8•21 years ago
|
||
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?
Assignee | ||
Comment 9•21 years ago
|
||
checked in on the trunk.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Comment 10•21 years ago
|
||
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+
Reporter | ||
Comment 11•21 years ago
|
||
[plussing to get onto my query radar]
Flags: blocking1.4? → blocking1.4+
Comment 12•21 years ago
|
||
adt: nsbeta1+/adt1 Please make sure this lands on the 1.4 branch resolving it by adding the fixed1.4 keyword. Thanks.
Updated•21 years ago
|
Keywords: fixed1.4
Whiteboard: [adt1] → [adt1][fixed on branch and trunk]
Target Milestone: --- → mozilla1.4final
Reporter | ||
Comment 13•21 years ago
|
||
vrfy'd fixed with both trunk and 1.4 branch builds (2003.05.29 commercial).
Status: RESOLVED → VERIFIED
Keywords: fixed1.4 → verified1.4
Updated•5 years ago
|
Component: Keyboard: Navigation → User events and focus handling
You need to log in
before you can comment on or make changes to this bug.
Description
•