Bug 134987 – Can't disable touch scrolling without disabling click events

• Component: DOM
• Status: RESOLVED LATER

[Rick Byers]

There doesn't seem to be any reliable way in mobile safari to prevent touches from causing scrolling while still receiving click events.  What's the right way for an app say bing maps) to support JavaScript driven touch panning while also handling taps.  Do they need to do their own tap detection in JavaScript?  If so, how can they ensure the tap gesture is entirely consistent with the built in one (eg. amount of movement permitted, any special targeting that occurs, etc.).

See more details here https://docs.google.com/a/chromium.org/document/d/12-HPlSIF7-ISY8TQHtuQ3IqDi-isZVI0Yzv5zwl90VU/edit#heading=h.yhiclz6b4bmv, and a specific example of a library relying on it's own tap gesture detection here: https://groups.google.com/a/chromium.org/forum/#!topic/input-dev/qINvLqmZ7eU

In chromium we have two solutions to this problem:
1) you can call preventDefault only on touchmove events.  This will reliably suppress scrolling/pinching without disabling 'click'.
2) you can use 'touch-action: none'

[Benjamin Poulain]

(1) does not work for us, you can move and still get a synthetic click.
(2) seems like a good solution. It is already covered by https://bugs.webkit.org/show_bug.cgi?id=133112

I would prefer a solution that does not involve mouse events. It would also be nice to have a system that handle precedence like input handling in native apps. I have no solution to propose at the moment.

I am gonna close for now. This bug is not really actionable at the moment (except for touch-action but I already have a bug for that).

[Rick Byers]

Alright, thanks.  We'll focus on touch-action as the right solution for this class of problems for now (I don't like recommending people rely on specific preventDefault behaviors - it's very subtle and browser-specific).

[Benjamin Poulain]

(In reply to comment #2)
> Alright, thanks.  We'll focus on touch-action as the right solution for this class of problems for now (I don't like recommending people rely on specific preventDefault behaviors - it's very subtle and browser-specific).

Honestly I think people should stick with touch for click when doing web apps until someone comes with a better solution.

The behavior of tap/click is way too subtle for the synthetic events. Take a basic table view for example:
-Touch down cause a highlight after a short delay.
-Sliding horizontally remove the highlight disclose the hidden actions.
-If you don't lift your finger, sliding back put you back in click mode.
-Panning vertically instead of horizontally cancel the click entirely.
-etc, etc

That is trivial to implement with native views. It is possible to implement such behaviors with touch events in JS (take the apps built on top of Sencha Touch). But good luck implementing that by mixing touch and synthetic events.

[Rick Byers]

I agree that complex cases will often necessitate dropping down to the low level APIs, but I think it's also important to give developers a rational set of higher level APIs for common scenarios that just work and do something reasonable.

For this reason I don't see 'click' and (:active) as 'synthetic'.  'click' has an unfortunate name ('activate' would be better) and prototype, but as for many things on the web this is an accident of history.  We fire 'click' for enter key presses too.  This is just a symptom of someone not having the foresight to define 'click' at the level of abstraction it would inevitably be used for.

Note I agree with you completely for 'mousedown' and 'mouseup'.  I'd love to stop sending these entirely in touch scenarios some day.

If we only give developers the choice between low level APIs where they have to build all interesting semantics themselves, and legacy compatibility APIs which are poorly defined and inconsistent between browsers then we're destined to always have a poor/inconsistent experience with touch (especially compared to what people are used to on desktop with mouse).

That said, if you think these scenarios are better addressed by defining new APIs (rather than rationalizing the ones we have) I'd love to work together on that.

[Benjamin Poulain]

(In reply to comment #4)
> If we only give developers the choice between low level APIs where they have to build all interesting semantics themselves, and legacy compatibility APIs which are poorly defined and inconsistent between browsers then we're destined to always have a poor/inconsistent experience with touch (especially compared to what people are used to on desktop with mouse).

We should aim at fixing all inconsistencies :)

> That said, if you think these scenarios are better addressed by defining new APIs (rather than rationalizing the ones we have) I'd love to work together on that.

Native apps have very powerful ways to handle input. What we have on the web today does not even come close to that.

There are two ways we can go about fixing that:
1) We can make touch events very reliable and powerful. Authors can then use preventDefault() systematically and implement advanced handling directly in JavaScript.
2) We could define higher level primitives like event filters and gesture recognizers, then provides the basic ones (pan, pinch, tap, etc) and let authors extend them and create new ones.

I think (1) is within short term reach. It is already possible to build very powerful apps if you target iOS only. I would love too see flawless compatibility of touch events and viewport within a year. Personally, I think reliability is far more important than extending the feature set at the moment.

I think (2) would be great for the platform but I doubt that will happen any time soon (if ever).

It seems to me that you are looking into a third way: use existing APIs to take advantage of the native gestures. It is definitely an interesting idea to achieve (2) without making new APIs, but I am afraid this may be limited.

Overall, I am just pained by how easy it is to build complex interactions with UIView compared to what you have to do on the web.

[Benjamin Poulain]

Looking back at this thread and the use case: I was more negative than I should have been. What you were asking is much simpler than the problems I have.

This bug is a good use case, we should try to support that with touch-action.

[Lucas Forschler]

Mass move bugs into the DOM component.