Opened 9 years ago

Closed 9 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 9 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 9 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 9 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 9 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 9 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 9 years ago by Eric Durocher

Cc: cjolif added

comment:3 Changed 9 years ago by bill

Eric -

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?

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.

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.

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.

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?

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.

Version 1, edited 9 years ago by bill (previous) (next) (diff)

comment:4 in reply to:  3 Changed 9 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 9 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 9 years ago by Eric Durocher

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

comment:7 Changed 9 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 9 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.