mouseStop

[Eduardo Lundgren]

If you are working with mouse iteractions mouseStop means: "the user stop all mouse events", for me this afirmation includes mouseUp, using this idea the mouseStop shouldn't be called at the same time than mouseUp.

What do you think in trigger the mouseStop one step after the mouseUp?

// trigger one step after - mouse plugin
setTimeout(function() { self.mouseStop(e); }, 0); ?



Imagine the user want to preventDefault event on a anchor when the drag starts and  reactivate the link when the drag stops.

on mouseStart: (you should consider distance=1px, like Richard supposed)

// prevent follow anchor the link if is target
if ($(e.target).is("a")) $(e.target).bind('click.preventFollow', function(e) {
      e.preventDefault();
 });

on mouseStop:

// re-activate the link
if ($(e.target).is("a")) $(e.target).unbind('click.preventFollow');

If you call the mouseStop at the same time than mouseUp this "unbind" will be triggered first than the "click" - The link will be followed.
If you call the mouseStop "one step" after mouseUp this "unbind" will be triggered after than the "click" - The link wont be followed.

Thoughts?

--
Eduardo Lundgren
Engenheiro de Software e Telecomunicações
tel: +55 81 92059691

[Scott González]

I'm not sure what all of the implications are of changing the current behavior.  I think we should put together a list of all the things we know plugins/users do with mouseStop before making a decision.

Couldn't this same functionality be implemented with:
if ($(e.target).is('a')) {
    $(e.target).one('click', function(e) { e.preventDefault(); });
};

[Richard D. Worth]

I think your idea is good. If I've understood correctly:

1. In all supported browsers except Opera, when you drag (mousedown, mousemove, mouseup) the mouseup is followed by a click
2. The click event doesn't make sense at the end of a drag (my words), and causes a problem if the user started dragging on a link (which can be followed assuming distance > 0, if no drag had started).
3. If dragging starts, we want to eat that final click following mouseup

If I've understood completely, I don't think this warrants a change to what mouseStop means, nor when it's triggered. I think (as you've shown below) we simply need to cancel that click that follows.

A few quick notes:
1. We should not just preventDefault, but return false (so that it doesn't bubble).
2. We should not limit this to links. Regardless of the element type, I don't think a click at the end of a drag makes sense, and is quite unexpected.
3. I know what you've written below is just pseudo-code, but for the unbind it can't be e.target, it needs to be a cached reference to the element, since there's no guarantee that mouseup happens on the same element as mousedown at the end of a drag. In any case, the click handler/eater should be unbound.

Otherwise, looks good.

Any chance this needs to be exposed so that each plugin can handle differently? Or are we safe saying "If a drag started, it shouldn't end with a click wherever mouseup happens"

- Richard

On Fri, Jun 13, 2008 at 12:28 AM, Eduardo Lundgren <bra...@gmail.com> wrote:

[Richard D. Worth]

This would work except click won't fire in all cases (Opera, mouseup is on different element than mousedown)

- Richard

[Eduardo Lundgren]

Richard you exposed my idea better, What I want is: "If a drag started, it shouldn't end with a click wherever mouseup happens"

guys?