314386 - Autocomplete: Tabbing or arrowing ignores entry position at mouse pointer

Status: RESOLVED FIXED

(Firefox :: Address Bar, defect)

Description

[Ed Lee :Mardak]

Steps to reproduce:
1. Activate autocomplete by typing a character
2. Move the mouse pointer to the 3rd selection (there should be at least 5 entries)
3. Press up/down or tab/shift-tab

Actual: The selected entry becomes the one relative from the top.
Expected: Selected entry should be above/below the entry the mouse was pointing to.

Last working version is from 20050805. Probably caused by fix for bug 302677. Not working correctly in 20051029 trunk as well as 20051022 branch.

Mike, is this the correct behavior for autocomplete? Enough time for 1.8rc2?

Comment 1

[Simon Bünzli]

Attachment: don't reset the selection on mouseout

Not sure why this mouseout handler is necessary. Works as expected without. If we really need it, currentIndex should probably be replaced with selectedIndex in order to update the visuals (resetting the selection).

Comment 2

[Simon Bünzli]

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

Comment 3

[Mike Beltzner [:beltzner, not reading bugmail]]

Did this get fixed somewhere else? Have I mitigated this review and patch merely by waiting it out? :)

I'm not seeing it in trunk or branch at the moment (on Mac). Please re-open if it still exists on windows. You've definitely got ui-r on ensuring we have the regression right, but should ask for code-review from someone else.

Comment 4

[Simon Bünzli]

I can still reproduce this with both the latest Minefield and Bon Echo nightlies.

Comment 5

[Mike Connor [:mconnor]]

wfm on bon echo a3, winXP sp2

Comment 6

[Simon Bünzli]

Steps to reproduce:
1. Open any autocomplete drop-down (e.g. the location bar's)
2. Hover the mouse over any item not being the first
3. Move the mouse outside the drop-down
4. Press down/tab

With that third step, it's still always reproducible on the latest trunk/branch nightlies.

Comment 7

[Mike Beltzner [:beltzner, not reading bugmail]]

Using those new STR, I see (using OS X 10.4, Intel)

 - tab moves focus to next element in the content area
 - if page is long enough, arrow keys cause page to scroll

To me, that seems like the event is being sent to the content area on mouseout.

Comment 8

[:Gavin Sharp [email: [e-mail]]]

Ah ha! I knew I'd seen this patch before (bug 174489 comment 12). I guess this fixes that bug too, right?

Comment 9

[Simon Bünzli]

I have my doubts. That bug is WORKSFORME already (probably fixed by bug 306538). Anyway, please just get finally rid of that useless line. :)

Comment 10

[:Gavin Sharp [email: [e-mail]]]

mozilla/toolkit/content/widgets/autocomplete.xml 	1.61
mozilla/toolkit/content/widgets/autocomplete.xml 	1.44.2.11