Item in location bar drop down highlighted after clicking same one on previous location bar usage.

VERIFIED FIXED in mozilla1.9.2a1

Status

()

Toolkit
Autocomplete
--
minor
VERIFIED FIXED
9 years ago
3 years ago

People

(Reporter: Tom, Assigned: dao)

Tracking

({verified1.9.1})

1.9.0 Branch
mozilla1.9.2a1
verified1.9.1
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

9 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3) Gecko/20090305 Firefox/3.1b3 (.NET CLR 3.0.04506.30)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3) Gecko/20090305 Firefox/3.1b3 (.NET CLR 3.0.04506.30)

When using the mouse to click on an item in the location bar drop down, the same item number is highlighted the next time the location bar is used. Pressing enter does not go to the highlighted link, and pressing tab goes to the next one down, not the first one as expected.

Reproducible: Always

Steps to Reproduce:
1. Go to location bar, type something in.
2. Click an item in the drop down list (say, the nth).
3. Go to the location bar again (e.g. press Ctrl+T), type something in (can be different). 
4. Wait for drop down list to open again. Don't use mouse!
Actual Results:  
The nth item down is highlighted. Enter does not open the highlighted link, it does a google search for what you typed. Tab goes to the n+1th link.

Expected Results:  
No items should be highlighted, pressing tab should highlight the first link in the list.

Tested on clean profile, still happens.
(Assignee)

Updated

9 years ago
Status: UNCONFIRMED → NEW
Component: Location Bar and Autocomplete → XUL Widgets
Ever confirmed: true
Product: Firefox → Toolkit
QA Contact: location.bar → xul.widgets
This reminds me of bug 408723. I can't reproduce it, but I could see it happening if your mouse moved slightly while hovered over the dropdown. Apparently that used to happen fairly frequently on Linux (perhaps because of a widget-level issue), but it could happen on Windows as well.

Could it be that your mouse or mouse driver is sending spurious move events?
Component: XUL Widgets → Autocomplete
QA Contact: xul.widgets → autocomplete
(Assignee)

Comment 2

9 years ago
I can reproduce it with a trackpad's separate mouse button, the pointer is definitely still while clicking. I have a working patch, but I'm not sure that it fixes it in the right place...
(Assignee)

Comment 3

9 years ago
And I can reproduce it even if I move the mouse away from where the popup would appear after 2.:

(In reply to comment #0)
> Steps to Reproduce:
> 1. Go to location bar, type something in.
> 2. Click an item in the drop down list (say, the nth).
> 3. Go to the location bar again (e.g. press Ctrl+T), type something in (can be
> different). 
> 4. Wait for drop down list to open again. Don't use mouse!
(Assignee)

Updated

9 years ago
OS: Windows XP → All
Hardware: x86 → All
(Assignee)

Comment 4

9 years ago
Created attachment 373551 [details] [diff] [review]
patch

I was going to ask Enn to review this, but since you already looked at the bug...
Assignee: nobody → dao
Attachment #373551 - Flags: review?(gavin.sharp)
I don't see how this could be happening given that we already set selectedIndex = -1 in a popuphiding handler:

http://mxr.mozilla.org/mozilla-central/source/toolkit/content/widgets/autocomplete.xml#884

Doing it on open is probably better anyways, but I'd still like to know why the bug currently occurs...
(Assignee)

Comment 6

9 years ago
(In reply to comment #5)
> I don't see how this could be happening given that we already set selectedIndex
> = -1 in a popuphiding handler:
> 
> http://mxr.mozilla.org/mozilla-central/source/toolkit/content/widgets/autocomplete.xml#884

At that point there's nothing to clear with the given STR. Somehow the item gets selected afterwards. Using the popuphidden event also doesn't help.
(Assignee)

Comment 7

9 years ago
Created attachment 373555 [details] [diff] [review]
patch v2
Attachment #373551 - Attachment is obsolete: true
Attachment #373551 - Flags: review?(gavin.sharp)
(In reply to comment #6)
> At that point there's nothing to clear with the given STR.

I'm not sure what this means. Are you saying selectedIndex is being set to something other than -1 after the popup's been hidden?
If that's the case, I don't see what could cause that other than a mousemove.
(Assignee)

Comment 10

9 years ago
(In reply to comment #8)
> (In reply to comment #6)
> > At that point there's nothing to clear with the given STR.
> 
> I'm not sure what this means.

There's no item with selected="true".

> Are you saying selectedIndex is being set to
> something other than -1 after the popup's been hidden?

Yes, to the item that you've clicked on.

I'll test if it's mousemove. In that case I would expect that doing selectedIndex = -1 during popuphidden fixes it, but it didn't.
The popup isn't hidden after 4), though, right?
(Assignee)

Comment 12

9 years ago
Right, it hides after 2.
I'm suggesting that a mousemove after 4) would explain this bug.
(Assignee)

Comment 14

9 years ago
It wouldn't explain why the item becomes selected after 2, when the popup is closed, and before 3. Also, if it was a mousemove after 4, the patches wouldn't fix this bug (but they do). Last but not least, see comment 3 -- there's no mousemove after 4, because the mouse isn't over the popup.
Maybe this would be easiest to debug by process of elimination. As far as I can tell there are only three places where selectedIndex is potentially set to something other than -1:

1) selectBy() in autocomplete.xml, called by nsAutoCompleteController::HandleKeyNavigation
2) mousemove handler in autocomplete.xml
3) nsAutoCompleteController::HandleDelete

I'd eliminated 1) and 3) because those shouldn't be called given those STR, but maybe something weird is going on. Can you figure out which of those is causing the selection after the first popup close?

Are you seeing this only on the trunk? Bug 376408 might be causing more autocomplete code weirdness there (as it did in bug 488311).
(Assignee)

Comment 16

9 years ago
This was reported with 3.1b3, and I'm also seeing it with 3.0.x.

selectedIndex is only being set once to something other than -1, and that's before you click on the item for step 2 (i.e. a mousemove). Following step 2, it's being set to -1 three times. After that, something else must be setting the "selected" attribute...
(Assignee)

Comment 17

9 years ago
It's the click handler in listbox.xml#listitem.
(Assignee)

Updated

9 years ago
Attachment #373555 - Flags: review?(gavin.sharp)
Ah, I can reproduce it now. I was typing more than one letter in step 3), which caused the list to repopulate itself and clear out the selection for some reason.
Attachment #373555 - Flags: review?(gavin.sharp) → review+
(Assignee)

Comment 19

9 years ago
http://hg.mozilla.org/mozilla-central/rev/9d055324a80c
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Flags: in-litmus?
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.2a1
Version: unspecified → 1.9.0 Branch
(Assignee)

Updated

9 years ago
Attachment #373555 - Flags: approval1.9.1?
(Reporter)

Comment 20

9 years ago
Thanks very much for your work on this Dão and Gavin, I really appreciate it. :)
Comment on attachment 373555 [details] [diff] [review]
patch v2

a191=beltzner
Attachment #373555 - Flags: approval1.9.1? → approval1.9.1+
(Assignee)

Updated

9 years ago
Keywords: checkin-needed
(Assignee)

Comment 22

9 years ago
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/f3550a7d6cef
Keywords: checkin-needed → fixed1.9.1
verified FIXED on builds:

 Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090527 Minefield/3.6a1pre ID:20090527031500

and

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1pre) Gecko/20090527 Shiretoko/3.5pre ID:20090527031214
Status: RESOLVED → VERIFIED
Keywords: fixed1.9.1 → verified1.9.1
(Assignee)

Updated

3 years ago
Flags: in-litmus?
You need to log in before you can comment on or make changes to this bug.