219706 - Using arrow keys to select drop down list box items selects two down or two up

Status: RESOLVED FIXED

(Core :: XUL, defect)

Description

[Michael Jolly]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030917 Firebird/0.6.1+
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030917 Firebird/0.6.1+

If I use the arrow keys to select an item in a drop down list box, it will not
select the next item, it will select the item 2 down or 2 up.

Reproducible: Always

Steps to Reproduce:
1. Open a drop down list box
2. Hit the up arrow or down arrow to select an item


Actual Results:  
If I am at the top of the list and hit the down arrow key, the third item is now
selected.

Expected Results:  
The second item should be selected.  Hitting the down arrow key again should
select the third item.

Comment 1

[Udo Bellack]

(In reply to comment #0)
> ...
> If I use the arrow keys to select an item in a drop down list box, it will not
> select the next item, it will select the item 2 down or 2 up.
> 
> Reproducible: Always
> 
> Steps to Reproduce:
> 1. Open a drop down list box
> 2. Hit the up arrow or down arrow to select an item
> 
> ...

I'm glad to find my bug after an hour of search here ... ;-)

My Config:
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031011
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031011

This phenomenon appears e.g. on the Mozilla-Mail->[V_i_ew] listbox or on the
Edit->Preferences->Appearance->Fonts->[Fon_t_s for:] listbox.
If the listbox has an uneven number of items, the down key scrolls first through
the uneven items and then through the even items (if 1 is selected by default)
Ex. for 5 items: 1->3->5->2->4->1...
If the listbox has an even number of items, you can reach only half of them,
depending on whether the first selection starts with an uneven or even item.

Comment 2

[Enrico Ferro]

I confirm the bug, it is present also in 0.6

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

this is a toolkit bug, so reassigning

Comment 4

[[e-mail]]

I can't reproduce this. Note that menulist up/down handling is in
nsMenuPopupFrame::KeyboardNavigation by way of nsMenuListener.cpp

Comment 5

[Brian Ryner (not reading)]

Attachment: patch

This only happens on gtk2, not sure if that would explain why Neil doesn't see
it. The problem is that nsMenuFrame::HandleEvent unconditionally sets the event
status to ConsumeDoDefault (even if it was already ConsumeNoDefault), so we
don't tell gtk that we consumed the event.  gtk then sends it up to the parent
widget (I think) and we get the event again.  gtk1 always does
gtk_signal_emit_stop_by_name() after handling a click event (regardless of the
event status)... I'm not sure if we want to do that on gtk2 or not, but I think
this fix to the menu code is correct either way.

Comment 6

[Brian Ryner (not reading)]

Comment on attachment 156229 [details] [diff] [review]
patch

mkaply, this code should look familiar, you had a hand in it a few years ago to
fix what sounds like a similar problem for os2.

Comment 7

[Mike Kaply [:mkaply]]

Comment on attachment 156229 [details] [diff] [review]
patch

Interesting.

hyatt removed my OS/2 fix in bug 45728 which noone ever told me.

So your fix theoretically should put things back to better than they were
before. cool.

Comment 8

[Asa Dotzler [:asa]]

*** Bug 254409 has been marked as a duplicate of this bug. ***

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 156229 [details] [diff] [review]
patch

sr=dbaron, although it seems to me that we shouldn't be allowing events to
bubble at the widget level, ever.

Comment 10

[Brian Ryner (not reading)]

checked in

Comment 11

[Calum Mackay]

*** Bug 228869 has been marked as a duplicate of this bug. ***

Comment 12

[Mike Kaply [:mkaply]]

Comment on attachment 156229 [details] [diff] [review]
patch

a=mkaply for 1.7.

Bryner, please check this into 1.7 and mark fixed1.7.x

Thanks

Comment 13

[Boris Zbarsky [:bzbarsky]]

*** Bug 265239 has been marked as a duplicate of this bug. ***

Comment 14

[Jeremy Bowers]

*** Bug 254327 has been marked as a duplicate of this bug. ***

Comment 15

[Jonathan Watt [:jwatt]]

I'm curious. Why not just leave the status as eIgnore? What distinction is being made between eIgnore and DoDefault here (or in general if anyone can shed any light on that)?

Does anyone know of any good reason not to merge eIgnore and DoDefault so we essentially have two-state allow/prevent default behaviour, instead of the three-state behaviour we have now?