Fix for nested mouse widgets breaks custom widgets

This ticket doesn't describe a bug at all. Please provide details about the problem you're having.

Previous to fix in e15c32d06763afd2376c61642397e7fc98338958 , plugins could check event.originalEvent.mouseHandled to see if the mouse had been handled already, and update it to allow other plugins to run. Now, plugins have no way of looking at this property or changing it.

In my plugin, which is patching ui.selectable to disable the drag-to-select behavior, I needed to set mouseHandled to false so that the ui.draggable plugin which is being used in conjunction, could still function on the click-and-drag of the mouse. The patch noted in this ticket adds the ability of inspecting the current mouseHandled status, and changing it.

Why are you not using the actual API of _mouseStart()?

I currently override _mouseStart, _mouseDrag, _mouseDown, and _mouseUp.

I probably could get away not using _mouseDown and instead use _mouseStart, but i definitely need to disable the _mouseDrag behavior in the parent ui.selectable and i use the _mouseUp to identify when click has completed so i can set the last-selected class on the last selected element.

Here is the current plugin. I'm no jquery ui expert, so if i should go about this another way, please let me know: http://jsfiddle.net/7Q7Vr/

The main point of the plugin is to allow ui.droppable to operate on tr's of a table, in combination with selectable on the tr's of the table

It sounds like you're doing something super hacky to work around bugs in our plugins.

thanks.