Scrolling blocked on Chrome

[sampaccoud]

I'm trying to use jquery.event.move.js v1.3.1 with Zurb Foundation's Clearing gallery, but when the plugin is in place, the scroll bar is inoperable in Chrome...

[stephband]

I have no idea what Zurb foundation's clearing gallery is. If you could
provide a URL for an example of your problem I might be able to help...
On 26 Nov 2012 16:14, "sampaccoud" notifications@github.com wrote:

I'm trying to use jquery.event.move.js v1.3.1 with Zurb Foundation's
Clearing gallery, but when the plugin is in place, the scroll bar is
inoperable in Chrome...

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/8.

[sampaccoud]

The problem was solved on Foundation Clearing by activating the swipe plugin only for touch screens (foundation/foundation-sites#1145)
...but it means the real remains within the plugin ?

[stephband]

It is perfectly normal that move cancels scroll, as it is assumed that you don't want to both move something and scroll something at the same time.

If you want to cancel a move, and thus have scroll work normally, then you can call e.preventDefault() in the movestart handler. If you want to enable scrolling in the vertical direction, but swiping in the horizontal, then you need to call e.preventDefault() conditionally, depending on which direction the user has started moving in movestart.

[septagram]

Dammit, I just compiled a perfect test case before bothering to look if anyone has asked this :(

Anyway, thanks for suggesting a workaround, but I have to disagree with you on that. The preventDefault() method is supposed to suppress the browser's default reaction to the event, not to 'unsupress' it.

Otherwise, this library is a lifesaver if you just want to implement a handful of simple touch events (I tried quo, but it had cross-browser issues, and hammer, but it was kind of slow). Thanks a lot for your hard work :)

[stephband]

Yes, preventDefault() is supposed to suppress the browser's default
reaction to a native browser event. But here we are not talking about the
native scroll event, we are talking about the move event. The default
reaction to the move event is to suppress scroll and listen to the movement
of the finger. I deliberately designed it to work this way.

If you look inside the move event, you'll see it's using jQuery's
event.special._default property, which allows us to give special events a
default behaviour - almost as if we are extending the native browser event
behaviours. So this is the way it is designed - as if it has default
behaviour, that you may suppress with preventDefault(), as if it were a
native event.

Thanks for the kind comments, it's great to hear it measures up to the
competition :)

On 28 October 2013 17:01, Septagram notifications@github.com wrote:

Dammit, I just compiled a perfect test casehttp://pumpkintime.org/default-failbefore bothering to look if anyone has asked this :(

Anyway, thanks for suggesting a workaround, but I have to disagree with
you on that. The preventDefault() method is supposed to suppress the
browser's default reaction to the event, not to 'unsupress' it.

Otherwise, this library is a lifesaver if you just want to implement a
handful of simple touch events (I tried quo, but it had cross-browser
issues, and hammer, but it was kind of slow). Thanks a lot for your hard
work :)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/8#issuecomment-27224951
.

[foxbunny]

Thanks for the kind comments, it's great to hear it measures up to the competition :)

Are you kidding? In many ways it's waaay better than the competition. 👍