330360 - Down-arrow in autocomplete list accepts first list item

Status: VERIFIED FIXED

(Thunderbird :: Message Compose Window, defect)

Description

[Mike Cowperthwaite]

TB 3a1-0309, Win2K

When a autocompletion list is shown in the compose window, typing the down-
arrow in order to select an address item in the list moves down to the first item, then immediately accepts that item (which, if domain-autocomplete is on, is the domain-autocompleted item).  It's not possible to select another address using the keyboard.  Mouse selection in the list works as expected.

Steps to reproduce:
1) Open a compose window
2) Type a substring that matches more than one address
3) Wait for the dropdown list to appear
4) Type <down>

Actual results:
4) Dropdown disappears; first item in list is accepted as the address.  Cursor moves to next address field (as if Enter had been typed).

Expected results:
4) Dropdown remains open with first item selected, and additional <down> can be typed to move further down in the list.

Workaround:
Use the mouse to select the desired address.

I don't see this behavior with 3a1-0303.

Comment 1

[Scott MacGregor]

I noticed this today too. 

On the surface this looks like it could be fall out from Bug 234455.

I'll try to dig some more.

Comment 2

[Mike Cowperthwaite]

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

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

I'll look at this later today, if no one else has found the problem before that.

Comment 4

[[e-mail]]

Attachment: Proposed patch

I'm guessing that preventBubble() doesn't work in capturing phase per spec?

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

(In reply to comment #4)
> Created an attachment (id=215109) [edit]
> Proposed patch
> 
> I'm guessing that preventBubble() doesn't work in capturing phase per spec?
> 
No it doesn't (well, per implementation, there is no spec for that), and we should get rid of preventBubble() and preventCapture().

I'm surprised that preventBubble did ever work...
Hmm, in the old code is there any difference between stopPropagation and preventBubble. I didn't test but by looking at the 1.8 code it seems that 
nsEvent.flags (note, not the other flags, which were also used in the event dispatching) had NS_EVENT_FLAG_INIT set during the whole dispatching.
And this means that
http://lxr.mozilla.org/mozilla1.8/source/content/events/src/nsDOMEvent.cpp#356
works always.

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 215109 [details] [diff] [review]
Proposed patch

If this fixes the problem, great. I didn't even know that thunderbird uses xpfe's autocomplete.

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

Now the question is, should we make preventBubble to work like stopPropagation.
Just for backward compatibility. I really wouldn't like to do that, but
if there is a lot of code which expects that preventBubble works also in
capture phase, then perhaps.

Comment 8

[Scott MacGregor]

re-assigning to Neil since he came up with the fix. 

Comment 9

[[e-mail]]

Fix checked in. Dunno how I overlooked it yesterday.

Comment 10

[Mike Cowperthwaite]

v with 3a1-0426, Win2K.