Scott,
what I said above is incorrect, in that way it is obviously impossible
to stop a "click" event to happen from a "mouseup" handler on the same
element.
However I looked back at how I did it and realize I removed the
"click" event handler before it happen:
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<script type="text/javascript">
window.onload = function() {
var element = document.getElementById('tester');
function logandstop(event) {
if (event.type == 'mouseup') {
if (element.removeEventListener) {
element.removeEventListener('click', logandstop, false);
} else {
element.detachEvent('onclick', logandstop);
}
}
top.status += ' * ' + event.type;
}
if (element.addEventListener) {
element.addEventListener('mousedown', logandstop, false);
element.addEventListener('mouseup', logandstop, false);
element.addEventListener('click', logandstop, false);
} else {
element.attachEvent('onmousedown', logandstop);
element.attachEvent('onmouseup', logandstop);
element.attachEvent('onclick', logandstop);
}
};
</script>
</head>
<body><div id="tester"><div>Click me !</div></div></body>
</html>
For the same "order" reason I gave in my previous post (mousedown
mouseup click) this will work cross-browser (tested FF3, IE6, Opera
9.6 & Safari 3.2). The "click" event is not fired and the order in
which the three handler are registered does not change the results.
I should add that in some cases I have also used an element overlay
technique similar to the one you described, to separate events on
different elements.
Diego
On 14 Feb, 03:10, Diego Perini <[email protected]> wrote:
> Scott,
> if I recall correctly, the solution to this maybe in the way the click
> event works.
>
> click = mousedown + mouseup
>
> if you setup three handlers, one for each of the above events you
> should see them fire in this order:
>
> mousedown - mouseup - click
>
> Don't use the alert() to show them they may appear in the wrong order,
> use top.status...
>
> Now (to cover different browsers) insert these lines in the "mouseup"
> handler:
>
> event.stopPropagation();
> event.preventDefault();
>
> event.cancelBubble = true;
> event.returnValue = false;
>
> return false;
>
> The "click" event shouldn't happen then.
>
> One or more of the above lines shouldn't be necessary but while
> testing you can leave them all, I really can't remember very well in
> this moment...I suggest you try this first with native methods on FF
> and see the result compared with those you can get with jQuery.
>
> Let me know if I did understand your problem correctly. The above
> seemed weird to me at first but there are reasons to it, so a quick
> test will hopefully take you out of doubts...or put more on me... :-)
>
> Diego
>
> On 13 Feb, 22:14, Scott González <[email protected]> wrote:
>
> > Not being able to guarantee the order does make this tricky. At least
> > for now, I'm just looking for something to improve our reliability in
> > UI, even if we don't provide this as a guaranteed method for putting
> > your handler at the top of the stack.
>
> > As for why we want to do this, we're modifying the defined behavior
> > that browsers provide. The draggable plugin provides non-native
> > functionality and creates non-native events. In addition to creating
> > new events, we believe that modifying the existing event system is
> > beneficial. So if you mousedown and mouseup on a draggable element
> > without dragging, then you should get a click event and no drag
> > events. However, if you do drag, you should get all of the drag
> > events (dragstart, drag, dragstop) and not get the click event, since
> > you performed a drag not a click.
>
> > Since we can't actually prevent the click event from being triggered,
> > the best we can do is cancel the click event as soon as it's
> > triggered. While writing this last sentence I had an idea that we
> > could throw a transparent div over the draggable as soon as dragging
> > starts. This would cause the mouseup to occur on a different element
> > than the mousedown and should prevent the click event altogether.
>
> > On Feb 13, 10:07 am, Brandon Aaron <[email protected]> wrote:
>
> > > Before we can answer that, we need to answer this question:
>
> > > Are we, as a library, guaranteeing the order of events as part of our API?
>
> > > The spec and browsers do not guarantee the order of events and our
> > > ordering
> > > is more a side-affect of how we currently handle the events.
>
> > > Even with your bindFirst method you cannot guarantee that your event will
> > > be
> > > the first when finally triggered. Why is the bindFirst method necessary?
> > > Why
> > > don't you want other subscribers to know the event was triggered?
> > > Shouldn't
> > > those subscribers be prepared to check if a particular change actually
> > > happened or not for some events?
>
> > > --
> > > Brandon Aaron
>
> > > On Fri, Feb 13, 2009 at 8:41 AM, Scott González
> > > <[email protected]>wrote:
>
> > > > We have a few places in jQuery UI where we need to prevent events from
> > > > occurring, e.g., preventing the click event after a drag. We've been
> > > > partially successful by just binding a handler and the click event and
> > > > returning false. This can be improved by calling
> > > > event.stopImmediatePropagation(), but that won't prevent handlers bound
> > > > before ours from running. The only solution I can come up with is to
> > > > force
> > > > our handler to be the first handler. With some help from Ariel, I've
> > > > put
> > > > togheter some code (http://codedumper.com/oxewu) and I'm looking for
> > > > some feedback. Is there some other way we can prevent event handlers
> > > > from
> > > > running? Are there still caveats like native onclick events?
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"jQuery Development" 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-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
