Menu: Item is hovered when navigating with keyboard

[sronsiek]

Where there are drop-downs with large numbers of options, keypress functionality comes into it's own. I have tried this in various browsers with and without this plugin, and have noted the following:

Without selectmenu: Open a drop-down, mouse happens to be over any of the options. The selected option is the one the mouse is over. Now select a different option via keyboard entry to select by leading letters of an option. On the last keyup the highlighted selection remains the one last selected via keyboard (the mouse has not moved).

Repeat the same with selectmenu, and the highlighting seems to go to the correct option, but then immediately jumps back to the option under the mouse.

It seems like a surplus mouseover event is being fired after the keyup - possibly only the first time.

[Scott González]

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

[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:

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.

[Scott González]

Replying to 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.

[Felix Nagel]

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.

[sronsiek]

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.

[Jörn Zaefferer]

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.

[tj.vantoll]

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

[Jörn Zaefferer]

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

[Giovanni Giacobbi]

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?

[Scott González]

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