Shouldn't fire when scrolled up from bottom

[neurofuzzy]

Hook should really only fire the reload when you're already at the top and try to scroll up. Not sure if you can detect that on all browsers but it works in OS X Chrome.

[fantattitude]

Yes, at the moment it's not very useful.

[cwacht]

Agreed. Preventing unintentional refreshes would be a fantastic feature addition.

[jordansinger]

I like the idea. But think about this in a real situation (I have no obligation against this idea): You are saying that when you are already at the top and try to scroll up, it refreshes. I think that would conflict with scrolling to the top if you were say half-way down the page, and scroll to the top. Think about it, when you scroll to the top you aren't going to react quickly enough to stop scrolling and stop the initiation of the refresh. Again, great idea, we just need to combine our heads and think of a unique way to tackle this subject.

[knightdr]

@jordansinger,

My guess is that scroll detection alone won't work. I think you'd have to do a combination of mouse drag and scroll events. OSX Webkit allows over scroll so it returns negative values but every other browser does not. That's where mouse drag would fill in the gap. If you've continued to drag 40px(or some value) while scrollTop is 0 show pull to refresh indicator.

[knightdr]

@jordansinger,

Oh and maybe mouse wheel as well. That's a lot of events to track so performance maybe/will an issue. If I have extra time, I'll see if this technique works at all in the browser.

Good luck

[cwacht]

Also touch events. I imagine Hook.js would really shine on touch devices where people are used to this method of refreshing.

[stryju]

found a way to differentiate the two events.
quick demo:

http://jsbin.com/ewadin/1/

would you care for a "fix" + pull request?