Opened 6 years ago

Closed 6 years ago

#16739 closed defect (fixed)

Scroll doesn't end correctly if the finger exit the touchscreen

Reported by: Sebastien Brunot Owned by: bill
Priority: undecided Milestone: 1.9
Component: DojoX Mobile Version: 1.9.0a1
Keywords: Cc: cjolif
Blocked By: Blocking:

Description

The problem can be reproduced on a iphone with iOS 6.0.1 on Safari, with the test page dojox/mobile/tests/test_TabBar-seg-grouped-scroll.html:

when the page is displayed, touch the center of the screen and move your finger to the bottom of the device until it leaves the screen: the scrollable list does not bounce back, it stays in the state it was when the finger left the screen (see the attached screenshot).

Attachments (2)

photo.PNG (76.2 KB) - added by Sebastien Brunot 6 years ago.
screenshot that shows the state of the screen when the finger leave it at the end of the scroll
missing_touch_end.patch (2.1 KB) - added by Eric Durocher 6 years ago.
Emit touchmove/touchend events when finger is out of the screen - Eric Durocher (IBM., CCLA)

Download all attachments as: .zip

Change History (10)

Changed 6 years ago by Sebastien Brunot

Attachment: photo.PNG added

screenshot that shows the state of the screen when the finger leave it at the end of the scroll

Changed 6 years ago by Eric Durocher

Attachment: missing_touch_end.patch added

Emit touchmove/touchend events when finger is out of the screen - Eric Durocher (IBM., CCLA)

comment:1 Changed 6 years ago by Eric Durocher

Owner: changed from Eric Durocher to bill
Status: newassigned

This is apparently caused by dojo/touch not firing touchmove and touchend events any more when the finger is moved out of the screen. The attached patch seems to fix the problem.

(I have a slight doubt on touchout: currently it is not fired when the finger has just been moved out of the screen since newNode == null, should it be fired with relatedTarget: null in that case?)

comment:2 Changed 6 years ago by Eric Durocher

Cc: cjolif added

comment:3 Changed 6 years ago by bill

(response edited)

Eric -

On 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.

Your patch is to emit touchmove/touchend events when your 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.

However, 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.

About other platforms besides webkit mobile: 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?

Your 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 your changes matches native touchmove behavior, but it's inconsistent with desktop.

Finally, 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.

PS: 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.

Last edited 6 years ago by bill (previous) (diff)

comment:4 in reply to:  3 Changed 6 years ago by Eric Durocher

Replying to bill:

(response edited)

Eric -

On 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.

The problematic cases are really when you never receive a touch.release. This happens on iPad when you move off the top of the screen (even if you move down again, the touches seem trapped by the notification pulldown). This does not happen on iPad when you move below the bottom of the screen (in that case you get a touchend), but it does happen on iPhone (no touchend when moving below bottom of screen, even if you moveup again inside the screen - that was the original case reported).

With native touch events, you never get to this situation (no touchend), as far as I can see on any device. There may be variations on whether you get move events when you move into the URL bar, or the footer bar when it exists. So I don't really care about move events, but we absolutely need a touch.release event.

Your patch is to emit touchmove/touchend events when your 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.

However, 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.cance

comment:5 Changed 6 years ago by Eric Durocher

... seems my answer did not get through completely :( well it was too long anyway and I am too lazy to write it again, so in short:

  • I still think we need at least the touch.release event to be fired whenever a native touchend was fired, otherwise it will break a lot of code and it will be inconsistent with the native touch events.
  • I more or less understand your points about touch.move, actually I am not so sure it is a real problem, a touchend is fired anyway as soon as you get to the border of the screen, so the only problem might be when you move over the header (URL bar) or footer of the browser, honestly I don't really care whether move events are fired there or not, I slightly prefer having move events to be consistent with native but I can live without them.

So, at least the single change in touchend seems necessary for me.

comment:6 Changed 6 years ago by Eric Durocher

And yes, MSPointerUp are fired in IE10 when you move out of the screen.

comment:7 Changed 6 years ago by bill

Milestone: tbd1.9

OK, I suppose if iOS sends a touchend event in that case then we can send it too. I'll set evt.target to <body> though so it doesn't give the impression that the finger was released over any specific node.

comment:8 Changed 6 years ago by bill

Resolution: fixed
Status: assignedclosed

In [30662]:

fire dojo/touch::end event when finger is dragged off the screen, since iOS does that natively, fixes #16739 !strict

Note: See TracTickets for help on using tickets.