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.
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
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...
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!
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...
(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.
Created attachment 373555 [details] [diff] [review] patch v2
(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.
(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?
Right, it hides after 2.
I'm suggesting that a mousemove after 4) would explain this bug.
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).
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...
It's the click handler in listbox.xml#listitem.
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+
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.2a1
Version: unspecified → 1.9.0 Branch
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+
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
You need to log in before you can comment on or make changes to this bug.