dojox/mobile/scrollable does not prevent touchmove default native event

[Sebastien Pereira]

According to W3C Touch Events ​http://www.w3.org/TR/touch-events/, function preventDefault() should be called on the first touchmove event to prevent any default action. Doing so (greatly) improves scrolling speed on some Android versions/devices (such as dojox/mobile/ScrollableView on the stock browser of Galaxy Tab 2 10.1" Android 4.1.1).

[Sebastien Pereira]

Calling preventDefault on "touch.move" event has no effect:

on(win.doc, touch.move, function(e){
e.preventDefault(); // no effect, no error
}

We first need to fix this to be able to add a preventDefault() call in scrollable.js on the first touch.move.

[Sebastien Pereira]

The preventDefault issue "touch.move" is addressed by this pull request: ​https://github.com/dojo/dojo/pull/11

[Sebastien Pereira]

Replying to seb:

The preventDefault issue with "touch.move" is addressed by this pull request: ​https://github.com/dojo/dojo/pull/11

[Bill Keese <bill@…>]

In 6647dcdb24a997a0d6183e0c94c2525b9ae4a8d4/dojo:

Error: Processor CommitTicketReference failed

Unsupported version control system "git": Can't find an appropriate component, maybe the corresponding plugin was not enabled? 

[Adrian Vasiliu]

Now that dojo/touch is fixed, remains to fix dojox/mobile/scrollable to add the missing call of preventDefault(). seb, please take care of it when possible.

[Adrian Vasiliu]

@bill, would you have any objection against backporting to 1.9 the dojo/touch fix you already committed in master?

[Bill Keese <bill@…>]

In 7305a1eb8b0c714689afe24c7271f9cc821c9e8d/dojo:

Error: Processor CommitTicketReference failed

Unsupported version control system "git": Can't find an appropriate component, maybe the corresponding plugin was not enabled? 

[Adrian Vasiliu]

So, seb, we still have to decide whether we add calls of preventDefault() to dojox/mobile/scrollable, and how exactly. Two elements about it (they do not drive to a clear conclusion but they are food for thinking):

1/ In recent testing on all devices we have (ios, BB, WP8, and Android with both stock browser and Chrome), we did not find any difference between no preventDefault() called in touchmove (as today), or calling it only for the first touchmove after touchstart, or for all touchmove events.

2/ Quotation: "Calling preventDefault() only on a second touch. One technique for preventing things like pinchZoom on a page is to call preventDefault() on the second touch in a series. This behavior is not well defined in the touch events spec, and results in different behavior for different browsers (i.e., iOS will prevent zooming but still allow panning with both fingers; Android will allow zooming but not panning; Opera and Firefox currently prevent all panning and zooming.) Currently, it's not recommended to depend on any particular behavior in this case, but rather to depend on meta viewport to prevent zooming." (​https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Events/Touch_events#Calling_preventDefault()_only_on_a_second_touch)

[Adrian Vasiliu]

Other relevant pieces on that matter:

​http://code.google.com/p/chromium/issues/detail?id=152913 and in particular ​http://code.google.com/p/chromium/issues/detail?id=152913#c26 which states (at least for Chrome) that "whenever you want to handle the touch events you should be calling preventDefault on the touchmove events to disable scrolling".

​http://lists.w3.org/Archives/Public/public-webevents/2013AprJun/0040.html goes in the same direction.

Surprisingly or not, things do not go the same for Android's stock browser, see ​http://code.google.com/p/android/issues/detail?id=19827 which is said fixed in 4.1 (unclear how exactly, though).

[Sebastien Brunot]

From which version of dojo is this problem fixed ?

[Adrian Vasiliu]

Nobody said it is fixed in any version. As you can read from the previous comments, it goes like that:

• A dojo/touch fix has indeed been committed in master and 1.9 branch.
• This fix was a prerequisite for addressing the issue described in this ticket.
• However, in time, we lost our full confidence that we really should go for the change in dojo/mobile/scrollable. It was (and still is) in the hands of the original reporter to draw a final conclusion about it.
• If nothing happens, we'll close it as "wontfix" or equivalent.

[Adrian Vasiliu]

To reflect the status quo about it, I'm closing the ticket. Of course, can be reopen if new input is received.