Skip to main content

Search and Top Navigation

#8866 closed bug (fixed)

Opened November 28, 2012 10:36PM UTC

Closed December 28, 2012 03:20AM UTC

Menu: select event not firing due to mouseHandled flag reset bug

Reported by: MrBigDog2U Owned by:
Priority: minor Milestone: 1.10.0
Component: Version: 1.9.2
Keywords: Cc:
Blocked by: Blocking:

The mouseHandled flag does not get reset properly when creating a menu within an event handler other than a button click.

The first time a menu is shown, the mouseHandled flag is set to false and the control works correctly. The .ui-menu-item click handler sets the mouseHandled flag to true but, if the menu is displayed a second time, the mouseHandled flag does not get reset. This results in the menu ignoring the .ui-menu-item click event in the second instance.

Attachments (0)
Change History (6)

Changed November 29, 2012 02:39AM UTC by tj.vantoll comment:1

Minified - I can see the behavior you're referring to but it's only happening for me when the

is created in a
. Not exactly sure what's going on there.

If you're looking for a workaround don't use

. Or for a better approach don't destroy and recreate the
on every button click -

Changed November 29, 2012 03:24AM UTC by MrBigDog2U comment:2

It will happen with other events as well - for example, when the menu is created in response to an AJAX success callback. This is the behavior that exposed the bug in the first place - my application requests data from the server and creates a menu with the information when the AJAX call returns. It behaves the same when the menu is created in response to a keyboard event (see Pretty much ANY event other than a mouse click.

As I explained in the initial description, this is due to errant handling of the mouseHandled flag in the If the menu is created in response to a button click event, then the "onclick" handler resets the mouseHandled flag AFTER the menu is created (thus resetting the flag). In response to ANY other event, the "onclick" handler either doesn't fire or fires before the menu gets created with the incorrect mouseHandled flag value. The workaround I have implemented is to add a mouseHandled reset to the _create method however I don't know if that approach will have side-effects in other parts of the widget.

I believe that I can use the approach of hiding and showing the menu like you demonstrated in your second jsfiddle link as a workaround that will not require changes to the jqueryui code.

Changed November 30, 2012 02:05AM UTC by tj.vantoll comment:3

status: newopen
summary: JQuery UI menu select event not firing due to mouseHandled flag reset bugMenu: select event not firing due to mouseHandled flag reset bug

Changed December 27, 2012 12:47PM UTC by jzaefferer comment:4

The mouseHandled flag is global, not per instance, so destroying the menu during the select event prevents the document-click handler from resetting the flag. Based on the current code I can't tell why that flag is there, would've have to work through some git logs to figure that out.

For now, I see two options: Make the flag per instance, so an invalid stage in one menu doesn't affect any others. Or reset the flag on _destroy.

Both would address the issue at hand, though it would be preferable to figure out why the flag is there in the first place and just get rid of it. For now, what TJ suggests is a better solution, since reusing the menu makes a lot more sense.

Changed December 27, 2012 12:51PM UTC by jzaefferer comment:5

Actually that was pretty easy to find:

Originally this was to remove the stopImmediatePropagation calls:

I tend to make that flag instance specific. I don't see why that needs to be shared across menu instances. Will ping Kris about it.

Changed December 28, 2012 03:20AM UTC by Kris Borchers comment:6

resolution: → fixed
status: openclosed

Create mouseHandled flag per instance instead of globally. Fixes #8866 - Menu: select event not firing due to mouseHandled flag reset bug

Changeset: 5143b7f672bc668963cce7dcf5dd4e2970aad8e5