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)
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•22 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•22 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•22 years ago
|
||
(side note: not theme specific, as it occurs in both modern and classic.)
Reporter | ||
Comment 4•22 years ago
|
||
aaron, any ideas what might be going on here?
Assignee | ||
Comment 5•22 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•22 years ago
|
Attachment #124324 -
Flags: superreview?(sfraser)
Attachment #124324 -
Flags: review?(brade)
Comment 6•22 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•22 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•22 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•22 years ago
|
||
checked in on the trunk.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Comment 10•22 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•22 years ago
|
||
[plussing to get onto my query radar]
Flags: blocking1.4? → blocking1.4+
Comment 12•22 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•22 years ago
|
Keywords: fixed1.4
Whiteboard: [adt1] → [adt1][fixed on branch and trunk]
Target Milestone: --- → mozilla1.4final
Reporter | ||
Comment 13•22 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•6 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
•