Menu: Item is hovered when navigating with keyboard

This is just how (some) browsers behave. The behavior isn't spec'd anywhere, but any browser that exhibits this bug is doing the right thing (this is a bug in the context of any widget that uses a menu, but not a bug in the context of a browser responding to elements moving on the page). To better understand what's happening, take a look at http://dev-test.nemikor.com/behavior/mouseover-when-element-is-shown.html

Related to #9496

I agree that this is behaviour that is not spec'd - however I think selectmenu should reflect the behaviour users encounter in modern browsers. And if you actually test this, you will see that this bug is not present in native browser drop-downs:

See jsfiddle.net/3vk47/

I have tested this with:

Win7: IE11, Google Chrome 35, Opera 23.0, Safari 5.1.7, Firefox ESR 31

Linux: Chromium 34, Firefox 30, Firefox 24 ESR

In all cases the behaviour is the same - the selection does NOT jump back under the cursor.

Pls also note that I have been liaising with the author of selectmenu - who has already fixed this issue in another version of selectmenu he maintains. See selectmenu#332. This ticket was raised at his suggestion!

He also confirmed my suspected cause - ie a surplus hover event following keyup - so my original title for this ticket was quite apt - I do not know why it was changed.

Replying to [comment:2 sronsiek]:

I agree that this is behaviour that is not spec'd - however I think selectmenu should reflect the behaviour users encounter in modern browsers. And if you actually test this, you will see that this bug is not present in native browser drop-downs:

I'm well aware of that. Native selects are generally rendered by the OS and have their own rules. Nobody has disagreed that this is a bug in selectmenu, so I'm not sure why you're still trying to prove that.

He also confirmed my suspected cause - ie a surplus hover event following keyup - so my original title for this ticket was quite apt - I do not know why it was changed.

We describe behavior, not technical cause, in ticket descriptions.

Would you mind to create a new demo fiddle as the former provided is no longer available (perhaps due to the latest DOS attacks on jsfiddle.net?). Just to make sure we talk about the same issue.

I've checked this and I'm able to reproduce the issue but only when a menu list with overflow is used. Using an overflow was needed to reproduce the bug in my fork too so I guess that's the issue you are talking about. Please confirm this assumption.

If so, I think we would need a check for an ongoing typeahead like in my fork: https://github.com/fnagel/jquery-ui/commit/9f9f61858ce4e62006dbea17aca446471f271a26

Something similar added to the mouseenter event function (https://github.com/jquery/jquery-ui/blob/master/ui/menu.js#L103-L109) should do the trick. I've tried to fix this but without a proper result. Perhaps Jörn can help here as he implemented the typeahead functionality afaik.

I've recreated the standard browser select at http://jsfiddle.net/sronsiek/ro034xLh/

I believe you are correct about the overflow statement - the bug only seems to occur with drop-downs with scroll-bars - though a drop-down may have the css overflow property set without actually displaying a scroll bar in auto. Not sure what happens in that scenario.

I can reproduce this in Chrome on OSX with http://view.jqueryui.com/master/tests/visual/menu/menu.html - tab to the scrolling menu ("Long menu with scroll overflow"), scroll down, then type "a" for the focus to move to some item at the top, scrolling the menu up. Afterwards the item that's now under the mouse will be focused. It happens whenever the menu scrolls due to the typeahead feature, otherwise the mouse is ignored.

Checking if the typeahead is active inside the mouseenter event handler seems to fix that issue: https://gist.github.com/jzaefferer/0b90e2639d96b6adfa3e and it doesn't break any unit tests. The worst this does is prevent focusing of items with the mouse for up to a second after the typeahead feature was used - I can't think of any scenarios where this would be problematic.

I suggested filing this as ui.menu, since that is where the problem actually is.

I agree with Jörn. I'm switching this to the menu component and marking the ticket as valid.

Menu: Ignore mouseenter events while typeahead is actice

Prevents focusing the wrong item when typeahead causes a scroll while the mouse

is over an item in the menu.

Fixes #10458

Changeset: ddc666ce8b95f34539864c0ddd87fee42123cbde

I would like to reopen this bug for two reasons:

1) The solution of blocking mouse events during typehead is suboptimal, this is not the behaviour that I want and I'm sure that many other users find it frustrating having to wait 1 second before the menu "unfreezes"\\\\

2) This is only a partial solution, as the exact same issue happens when scrolling with arrows, which doesn't account for the typeahead.

I tested this on Firefox 43.0.1, using the Long menu example already mentioned in previous comments ''(side note: i have to click the scrollbar of the menu before I can use the arrows or typeahead feature, wanted behaviour?)''. Simply put your mouse in the middle and use arrow down to scroll, holding it or pressing repeatedly yields the same result.

I believe the right solution is to detect scrolling events and block mouse events only in that specific case. Do you think it's feasible by storing and checking the scrolling offset?

Since this shipped a long time ago and you're expanding on the original ticket, please open a new ticket.