Bug 133112

hah, seems Jorik beat me to it. feel free to de-dup between this and https://bugs.webkit.org/show_bug.cgi?id=133114

FYI there are several reasons we decided to add touch-action to blink. Eg. from https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/sc5lHnlcLvM/ntJWuKKHUqYJ: 1. Provides precise control over the dreaded 300ms click delay on mobile 2. Reliably enables side-swipe UIs (frees libraries from having to predict when exactly scrolling may start on different browsers) 3. Enables high-fidelity polyfills of pointer events (eg. as in Polymer) 4. Provides a declarative signal to blink (and potentially the compositor) about the developers intent wrt. touch input - eg. providing a potential solution the touchstart ACK timeout problem 5. Reducing confusion around the highly-overloaded response to preventDefault on touch events 6. A prerequisite for future optimizations to enable scrolling and zooming that never block on the main thread It's #5 that seems to resonate most with typical web developers. In particular I continue to see developers struggle with implementing side-swipe UIs (#2), and I believe mobile safari requires them to reverse-engineer a magic distance threshold number (which then imposes a compat burden on the web no to change that magic value).

*** Bug 133114 has been marked as a duplicate of this bug. ***

Adding this from https://bugs.webkit.org/show_bug.cgi?id=133114 here: Although there seems to be no immediate desire to implement the full Pointer Events specification (see https://bugs.webkit.org/show_bug.cgi?id=105463), it may be worth considering at least supporting the touch-action:manipulation CSS property/value. This recent addition (the "manipulation" value) to the Pointer Events specification is used - in essence - to allow developers to suppress the classic 300ms delay present on touchscreen devices that by default allows for "double-tap to zoom", while retaining other abilities such as scrolling and pinch-to-zoom. It offers a compromise to the often drastic preventDefault() commonly used in touch-optimised applications (which does remove the 300ms delay, but also kills any other default interactions). touch-action:manipulation is on track to be rolled out in both Firefox and Chrome - see "Bug 979345 - Implement "touch-action: manipulation" CSS value for Pointer Events" https://bugzilla.mozilla.org/show_bug.cgi?id=979345 "Issue 349016: Add support for touch-action: manipulation" https://code.google.com/p/chromium/issues/detail?id=349016

Some context: I do not have time to experiment with touch-action at the moment. If someone is interested in contributing patches to WebKit, I would be happy to provide guidance and reviews. Rick: some questions about the spec: -At the moment, pan-x and pan-y are pretty much useless for every use case we have. We would need the touch action to have the direction, eg. pan-positive-y/pan-negative-y or pan-y-downard/pan-y-upward. Is there anything like that in the work? -Is it specified in what coordinates system are the x/y for pan-x/pan-y? Is it in the block coordinates? Its containing block? The whole frame? The main frame? Patrick: touch-action:manipulation is basically just as bad as preventDefault() for the click delay. Touch events have raw position, mouse/click events are adjusted based on the device DPI, scale factor, finger surface, etc. For tap/click, the right thing to expose is the adjusted value, not the raw touch. The problem is touch-action:manipulation defines touch behavior, not synthetic events. The synthetic mouse events are superior to touch events for tap/click. I still welcome a real proposal to that issue (IIRC, you had opened a bug for that?).

"Patrick: touch-action:manipulation is basically just as bad as preventDefault() for the click delay. Touch events have raw position, mouse/click events are adjusted based on the device DPI, scale factor, finger surface, etc. For tap/click, the right thing to expose is the adjusted value, not the raw touch. The problem is touch-action:manipulation defines touch behavior, not synthetic events." Unless I'm missing something, all that touch-action:manipulation in the context of touch events would do (and I believe that's what Chrome and Mozilla are implementing/have implemented so far) is a rather fancy way of saying "don't wait 300ms for the second tap of a double-tap action". Nothing about affecting raw vs adjusted position values as far as I know.

"The synthetic mouse events are superior to touch events for tap/click. I still welcome a real proposal to that issue (IIRC, you had opened a bug for that?)" Yes, it's https://bugs.webkit.org/show_bug.cgi?id=122212 (where we got a bit sidetracked by the fantastic hidden feature is iOS that not even power users know about that is double-tap-to-scroll ;) )

Just a couple additional thoughts/responses: Definitely agree that "synthetic" events (esp. click) are far superior for activation behaviors. Other goodness here too like better accessibility. * Note that IE11 now uses the PointerEvent interface for click and will even fire it for multi-touch provided you aren't zooming. So we don't really consider it a "synthetic" event in this regard. Like Patrick says, touch-action doesn't affect whether you a browser alters coordinate accuracy (in fact, such adjustment is out of scope for our working group) touch-action: manipulation is about restricting touch behaviors to "scrolling and continuous zooming" aka, disabling features like double-tap-to-zoom * This in turn enables browsers to optimize out the 300ms delay for synthetic events like click, but isn't technically a required feature of the API pan-x/pan-y work well for many common "native" experiences like carousel photo galleries, swiping pagination, etc. * The working group has discussed additional values like pan-positive-y/pan-negative-y. It's not in the spec or implementations, but we'd love to have you participate in the WG discussion and discuss use cases we should be solving. I'm thinking we'll tackle this in Pointer Events V2, which is on the near horizon.

(In reply to comment #8) > Just a couple additional thoughts/responses: Thanks for participating. > touch-action: manipulation is about restricting touch behaviors to "scrolling and continuous zooming" aka, disabling features like double-tap-to-zoom > * This in turn enables browsers to optimize out the 300ms delay for synthetic events like click, but isn't technically a required feature of the API I disagree, but that's a completely different problem. Please have a look at https://bugs.webkit.org/show_bug.cgi?id=133112. > pan-x/pan-y work well for many common "native" experiences like carousel photo galleries, swiping pagination, etc. > * The working group has discussed additional values like pan-positive-y/pan-negative-y. It's not in the spec or implementations, but we'd love to have you participate in the WG discussion and discuss use cases we should be solving. I'm thinking we'll tackle this in Pointer Events V2, which is on the near horizon. On OS X or iOS, we fully support scrollview-inside-scrollview.

>> pan-x/pan-y work well for many common "native" experiences like carousel photo galleries, swiping pagination, etc. >> * The working group has discussed additional values like pan-positive-y/pan-negative-y. It's not in the spec or implementations, but we'd love to have you participate in the WG discussion and discuss use cases we should be solving. I'm thinking we'll tackle this in Pointer Events V2, which is on the near horizon. >On OS X or iOS, we fully support scrollview-inside-scrollview. Not sure I follow how that relates to touch-action. IE (and Chrome/Firefox I think) supports this too. Can you explain further?

(In reply to comment #10) > >> pan-x/pan-y work well for many common "native" experiences like carousel photo galleries, swiping pagination, etc. > >> * The working group has discussed additional values like pan-positive-y/pan-negative-y. It's not in the spec or implementations, but we'd love to have you participate in the WG discussion and discuss use cases we should be solving. I'm thinking we'll tackle this in Pointer Events V2, which is on the near horizon. > > >On OS X or iOS, we fully support scrollview-inside-scrollview. > > Not sure I follow how that relates to touch-action. IE (and Chrome/Firefox I think) supports this too. Can you explain further? Let's say we would want to change all the carousels to touchAction instead of gesture recognition from touch events. Let's say the carousel start in the middle. -In that first state, only pan-y is enabled, pan-x is handled through the touch events. -You pan to the right edge. -You rubberband or stop at the edge, but either way, the last position is maxX. -Now we have two cases: -If you continue panning to the right, the superview should take the gesture and track it from there. -If you start panning in the other direction, then view takes the touch events and tracks the input. If you can specify the direction, you change change the touch-action based on the internal state of the carousel.

Ah, makes sense. When I use "carousel" I usually mean the ones that wrap around like the kids' ride. They're usually moving things from the beginning to the end of the scroller or vice-versa to create the illusion of a full carousel loop. So you never hit this issue and pan-x/pan-y work just fine. But, not all work this way and I agree the positive/negative values would improve the experience. Though I like a solution like CSS Scroll Snap Points to enable this to be built with native scrolling instead. "Pull to refresh" was another scenario we had in mind for positive/negative pan values (so you could enable touch events when pulling down at the top of a scroller, to animate the refresh icon or something; but then still have native scrolling for the rest of the scroller). Though I understand there may be some complicated issues for Apple to work through to join, it'd really be great if we could continue the positive/negative discussion over in the working group (I don't think we really want to design the API here in the webkit bug).

(In reply to comment #12) > Ah, makes sense. When I use "carousel" I usually mean the ones that wrap around like the kids' ride. They're usually moving things from the beginning to the end of the scroller or vice-versa to create the illusion of a full carousel loop. So you never hit this issue and pan-x/pan-y work just fine. > > But, not all work this way and I agree the positive/negative values would improve the experience. Though I like a solution like CSS Scroll Snap Points to enable this to be built with native scrolling instead. Snap points is a good idea to investigate regardless. There will still be cases when people want full control with JavaScript. With iOS, we try to give as much power as possible to the web page. Generic solutions to provide a near native experience for a large variety of use cases are very useful to have. I can see touch-action being useful there. > "Pull to refresh" was another scenario we had in mind for positive/negative pan values (so you could enable touch events when pulling down at the top of a scroller, to animate the refresh icon or something; but then still have native scrolling for the rest of the scroller). > > Though I understand there may be some complicated issues for Apple to work through to join, it'd really be great if we could continue the positive/negative discussion over in the working group (I don't think we really want to design the API here in the webkit bug). I really doubt that is gonna happen. I don't think I will have useful comments before prototyping anyway.

This bug depends on https://bugs.webkit.org/show_bug.cgi?id=149854

Implement touch-action: manipulation; for iOS https://bugs.webkit.org/show_bug.cgi?id=149854

This tracks support for the auto and manipulation values: https://bugs.webkit.org/show_bug.cgi?id=149854 Are there plans to implement none as well? Besides the performance optimizations this could enable, support for parsing none will help libraries like: https://github.com/jquery/PEP/issues/250

Note: some discussion of the need for more touch-action values (like pan-y) in order to be able to opt-in to passive event listeners: https://github.com/WICG/EventListenerOptions/issues/56

<rdar://problem/31302639>

What is the status of touch-action on Desktop Safari 10 onwards? According to caniuse.com, auto and manipulation are supported but using feature queries as the test yields a negative result (i.e. none of the touch-action values are supported). Tested on Safari 10.1 and Safari TP 27. Link to test page: https://www.chenhuijing.com/touch-action

`touch-action: none` would enable a very elegant solution to the diabolical situation of trying to manage pop-ups with scrolling areas on iOS. See: https://benfrain.com/preventing-body-scroll-for-modals-in-ios/ for examples. The solution outside of iOS/Safari is to use `touch-action: none`; simple and effective. There seems no clean solution to the issue on iOS outside of WebKit implementing `touch-action: none` but I would welcome any evidence to the contrary?

It would appear that pointer-events: none doesn't work in iOS 11.0.0 – anyone else having this issue?

(In reply to Richard Cook from comment #21) > It would appear that pointer-events: none doesn't work in iOS 11.0.0 – > anyone else having this issue? assuming you mean touch-action:none, that never worked in iOS. touch-action:manipulation does, however. see https://patrickhlauke.github.io/touch/tests/results/#suppressing-300ms-delay

(In reply to Patrick H. Lauke from comment #22) > (In reply to Richard Cook from comment #21) > > It would appear that pointer-events: none doesn't work in iOS 11.0.0 – > > anyone else having this issue? > > assuming you mean touch-action:none, that never worked in iOS. > touch-action:manipulation does, however. see > https://patrickhlauke.github.io/touch/tests/results/#suppressing-300ms-delay I have only just realised this but it worked in iOS 10 to prevent the clicking of an element that was set on a higher z-index but opacity: 0 and pointer-events: none. But in iOS 11... nope.

(In reply to Richard Cook from comment #23) > I have only just realised this but it worked in iOS 10 to prevent the > clicking of an element that was set on a higher z-index but opacity: 0 and > pointer-events: none. But in iOS 11... nope. I'd suggest opening a new bug then, as this bug is about touch-action, not pointer-events

Any updates on this issue? According to "Can I use" (https://caniuse.com/#feat=css-touch-action) Safari still does not support the CSS touch-action property. I'm working on the three.js project and it would be really great for 3D controls development to have this feature available in all major browsers.

Any plans to add touch-action: none?

Would love to see this implemented as well...

touch-action: none, will prevent the body scrolling when the Modal div is open? >>> that is when the fixed pos modal div is open, I will set the touch-action: none to the <body> element and will add the touch-action: automatic to the modal <div> in that case i will prevent the touch action on body so that i will stop scrolling the body when the user comes to the end of the modal window. Like to have the touch-action:none in IOS Safari.

(In reply to Mohamed Hussain S H from comment #28) > touch-action: none, will prevent the body scrolling when the Modal div is > open? > > >>> that is when the fixed pos modal div is open, I will set the touch-action: none to the <body> element and will add the touch-action: automatic to the modal <div> in that case i will prevent the touch action on body so that i will stop scrolling the body when the user comes to the end of the modal window. > > Like to have the touch-action:none in IOS Safari. Reference : https://benfrain.com/preventing-body-scroll-for-modals-in-ios/

Having some easy method of preventing unwanted scrolling of the body element would be great, when implementing custom modal dialogs/overlays. Either this, or then overscroll-behavior would be very much appreciated!

An implementation of touch-action when in r240579 for https://bugs.webkit.org/show_bug.cgi?id=193447. I'll be working on a macOS implementation in the next couple of months as well.

Sounds great! Please notify us when it's possible to test this with build.

For macOS all we need to do is decide whether to expose the property since it's effectively only relevant with a touch-capable display. Chrome and Firefox on macOS expose the property, but I'm not sure it's right to expose it. Anyone here have thoughts on the topic?

any particular reason NOT to expose it? are there similar situations where a property is only exposed when particular hardware/environment is present? (thinking ahead, would like to avoid naive "test for the presence of this property to determine if it's a touch device" type detects, as they're not recommended/are usually abused)

(In reply to Patrick H. Lauke from comment #34) > any particular reason NOT to expose it? are there similar situations where a > property is only exposed when particular hardware/environment is present? > (thinking ahead, would like to avoid naive "test for the presence of this > property to determine if it's a touch device" type detects, as they're not > recommended/are usually abused) I agree with this. We should always expose the property, even if it may have no effect on some devices. It's what other browsers do and it seems consistent with other "hint" type properties.

OK, the touch-action property will be exposed on macOS.

Created attachment 363213 [details] Patch

Comment on attachment 363213 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=363213&action=review > LayoutTests/ChangeLog:3 > + Touch-action css property support You need a title that is specific to this commit, which seems to be about enabling tests.

Comment on attachment 363213 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=363213&action=review >> LayoutTests/ChangeLog:3 >> + Touch-action css property support > > You need a title that is specific to this commit, which seems to be about enabling tests. Agreed.

The final step to enable the WPT tests is tracked by 195204. This is all done.

Will touch-action: pan-y be supported? (by mobile Safari)

(In reply to Tobi Reif from comment #41) > Will touch-action: pan-y be supported? (by mobile Safari) `touch-action: pan-y` is supported in Safari on iOS 13. If you find a situation where it does not work as expected, please file a bug.

> `touch-action: pan-y` is supported in Safari on iOS 13. > If you find a situation where it does not work as expected, > please file a bug. It's a bit complicated, and I unfortunately don't have the time to provide a reduced test-case. The issue is this: When I load https://tobireif.com/posts/layout_fun_with_css_grid/ eg on a Galaxy phone (eg in Chrome), and drag the "resize"-bar (below "Another demo"), and over-drag, the handle stops moving. So I add touch-action: pan-y – now when I over-drag, the handle follows. And when I drag the grid demo itself, I get normal y-axis scrolling of the page. When I load this in the iPhone simulator app (iOS 13 iPhone 8), and over-drag the resize-bar, it (sometimes) doesn't follow. For example: drag-resize the in-page demo to narrow, over-drag, then go back all the way. Do this once or eg twice -> the drag-handle stops following. So I added this hack: (function() { isMobileSafari = /iP(ad|hone|od)/i.test(navigator.userAgent); if (isMobileSafari) { demo.style.touchAction = "none"; } })(); Now there's no issue with the drag-handle (it always follows), but I don't get any scrolling (the page doesn't move when I try to drag the demo itself up/down). But page-scrolling is very important :/ I hope that you can reproduce all this (probably by toggling stuff via the dev-tools), and that the issue(s) can get fixed soon. Then I can remove the iPhone hack. In Chrome (eg on a Galaxy phone) everything works beautifully.

Reported (as requested) as a separate bug: https://bugs.webkit.org/show_bug.cgi?id=202531