Skip to main content

Search and Top Navigation

#10458 closed bug (fixed)

Opened August 02, 2014 06:28PM UTC

Closed August 27, 2014 04:49PM UTC

Last modified February 15, 2016 09:17PM UTC

Menu: Item is hovered when navigating with keyboard

Reported by: sronsiek Owned by: sronsiek
Priority: minor Milestone: 1.11.2
Component: ui.menu Version: 1.11.0
Keywords: Cc:
Blocked by: Blocking:
Description

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.

Attachments (0)
Change History (11)

Changed August 02, 2014 07:32PM UTC by scottgonzalez comment:1

status: newopen
summary: selectmenu: Surplus event following keyupSelectmenu: 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

Changed August 03, 2014 10:43AM UTC by sronsiek comment:2

_comment0: \ 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: \ \ See [http://jsfiddle.net/3vk47/ 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 [https://github.com/fnagel/jquery-ui/issues/332 selectmenu#332]. \ \ 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. \ \ \ \ \ \ 1407062721175232
_comment1: \ 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: \ \ See [http://jsfiddle.net/3vk47/ 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 [https://github.com/fnagel/jquery-ui/issues/332 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. \ \ \ \ \ \ 1407062776426458

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.

Changed August 03, 2014 01:08PM UTC by scottgonzalez comment:3

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.

Changed August 07, 2014 04:45PM UTC by fnagel comment:4

owner: → sronsiek
status: openpending

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.

Changed August 08, 2014 07:17AM UTC by sronsiek comment:5

_comment0: \ I've recreated the standard browser select at [http://jsfiddle.net/sronsiek/ro034xLh/] \ \ I believe you are correct about the oberflow 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. \ \ \ \ \ \ 1407484919743608
status: pendingnew

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.

Changed August 14, 2014 01:14PM UTC by jzaefferer comment:6

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.

Changed August 14, 2014 01:25PM UTC by tj.vantoll comment:7

component: ui.selectmenuui.menu
status: newopen
summary: Selectmenu: Item is hovered when navigating with keyboardMenu: Item is hovered when navigating with keyboard

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

Changed August 27, 2014 04:49PM UTC by Jörn Zaefferer comment:8

resolution: → fixed
status: openclosed

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

Changed August 27, 2014 04:52PM UTC by scottgonzalez comment:9

milestone: none1.11.2

Changed February 15, 2016 06:49AM UTC by thg2k comment:10

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?

Changed February 15, 2016 09:17PM UTC by scottgonzalez comment:11

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