Open skeggse opened 10 years ago
This happens because when you move your mouse out of the bounds of the browser, events are lost. This happens with iFrames, too, and I don't believe there is a fix for this without wasting resources like you described.
You already have an event listener for mousemove, no? The following seems to work when added to the beginning of the dragging
function:
dragging: function(e) {
if (cache.isDragging && settings.touchToDrag) {
if ('which' in e ? e.which === 0 : e.button === 0) {
return action.drag.endDrag(e);
}
// ...
}
}
This wouldn't handle the case of the mouse moving on anything but the snap-content, but that's a lost cause anyway.
@jakiestfu I've tested it a bunch, and it seems fine. I don't know about Internet Explorer, but it should work.
Would you like to send a pull request?
@jakiestfu have you checked out the pull request?
Bump
@skeggse This will DEFINITELY make the v2.0 release of Snap.js, expect it soon, thanks for your help!
Heheh what's the news on snap.js v2.0?
If you drag the drawer out, but release the mouse outside the bounds of the browser, Snap.js will not detect the mouse's state correctly. It will continue to act as if the button is stuck down, parenting the content to the cursor. In many browsers, the event passed to the
mousemove
listener will include either awhich
property or abutton
property containing the button(s) currently active. Inspecting the mousemove event could mitigate this issue. Of course, the mousemove listener is fired rapidly, so performance may take a hit.