Hi there - We are noticing an issue with the core behaviour of the mouse plugin - it seems that $.ui.mouse goes to some efforts to make sure that the event return code, for example, for mouseDown is true/false as appropriate - but it would seem that preventing the default event semantic could sometimes be problematic.
A particular case is its use, for example, in ui.draggable. Given that *all* mouseDown events targetted at a node which is a draggable, which are "acceptable drag start events" are trapped to return false, this means that standard focus/blur semantics no longer operate in the node. We have created a simple test case here: file:///E:/workspace/fluid-components/src/webapp/tests/jquery-tests/manual/jQueryUI-focus-test.html Without MIP applied to the node, clicking at different locations within it operate default focus/blur. Once MIP is applied (in this case, via making it draggable(), but this could have occurred by other means), it is no longer possible to cause a blur() to be delivered via clicking within the node. One solution to this might be to override the mouseCapture method to refine the set of nodes which cause an MIP start on mouseDown - however, this would seem to be more the responsibility of an extending widget rather than that of clients of the widget themselves. Also, this still creates the situation where a click which *might* be a drag start, does not also cause the default browser blur() for some currently focused item. What would be the consequences for overall JQuery UI architecture if mouseDown never made a return of false? Cheers, Antranig. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "jQuery UI" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jquery-ui?hl=en -~----------~----~----~----~------~----~------~--~---
