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)

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: 21 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: