Changes between Version 1 and Version 2 of Ticket #16739, comment 3


Ignore:
Timestamp:
Feb 22, 2013, 5:42:33 AM (9 years ago)
Author:
bill
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #16739, comment 3

    v1 v2  
     1(response edited)
     2
    13Eric -
    24
    3 My first question is, do you get an MSPointerUp event when dragging your finger off the viewport and then releasing your finger while it's (for example) over the URL bar?
     5On iPad, you can drag your finger off the viewport to the URL bar, and then drag it back on to the viewport again, and scrolling continues correctly... so ideally just moving your finger off the viewport wouldn't trigger a touch.end event.   However, I guess the problem is if you drag your finger to the URL bar and then release it, in which case there's no notification.
    46
    5 On iPad, you can drag your finger off the viewport to the URL bar, and then drag it back on again, and scrolling continues correctly... so ideally just moving your finger off the viewport wouldn't trigger a touch.end event.   However, I guess the problem is if you drag your finger to the URL bar and then release it, in which case there's no notification.   So, I see the argument for firing a touch.end event when your finger is dragged off the viewport.
     7Your patch is to emit touchmove/touchend events when finger moves off the viewport.   I can see how that will fix the problem with dojox/mobile, and also if you could do the same on desktop I can see how it would fix some problems there, like dojo/tests/dnd/test_moveable.html on IE8, moving the cursor off viewport while dragging a node and then doing mouseup, but the node is still in a drag state.
    68
    7 Firing a touch.end event when your finger is dragged off the viewport is inconsistent with desktop since you don't get a mouseup event when you drag the mouse off the browser window... but then again, that leads to problems, for example running dojo/tests/dnd/test_moveable.html on IE8, moving the mouse off viewport while dragging a node and then doing mouseup, but the node is still in a drag state.   So maybe that should be changed too.
     9However, the patch seems dangerous in general.  For example, imagine the viewport is split into four quadrants, and you can drag & drop items between those four containers.   Dropping an item off viewport probably shouldn't drop it in the last quadrant it was over, but rather the drag operation should be canceled.   So dropping off viewport sounds like a touch.cancel event, not a touch.end event.
    810
     11Also, desktop doesn't give a mouse up event unless the user actually releases the mouse.    Do you get an MSPointerUp event when dragging your finger off the viewport?
    912
    10 Likewise with touch.out, it sounds semi-reasonable to fire a touch.out event with target: oldNode and relatedTarget: null, although I wonder what desktop does (when you drag the mouse off the browser window).   I'm also uneasy about having relatedTarget:null since it sounds non-standard and might break code expecting that attribute to be set.
    11 
    12 Your change to dojotouchmove handling seems strange though.  A node will only get a mousemove event when the new mouse coordinates are over the node.   Why should touch.move act differently?
     13Your change to dojotouchmove handling seems strange also.  A node will only get a mousemove event when the new mouse coordinates are over the node.   Why should touch.move act differently?   I guess that matches native touchmove behavior, but it's inconsistent with desktop.
    1314
    1415Finally, I'm wondering if the dojox/mobile code mentioned in this ticket should even be using dojo/touch.   From what I've seen on iPad/iPhone, once you touch an inner <div> to start scrolling it, you can continue scrolling it by moving your finger off of the <div> to other positions on the screen.  So setting up a touch.move listener on an inner <div> doesn't match native iOS behavior.   If however the touch.move listener is on <body> then I guess that's OK.
     16
     17PS: About touch.out, it does sound nice to have a touch.out event on <body> if you move off the viewport, although that might break code that's expecting relatedTarget to have a non-null value.