search

w3c / pointerevents

Pointer Events
https://w3c.github.io/pointerevents/
Other
68 stars 33 forks source link

touch-action: disable webview swipe back behavior #358

Open liamdebeasi opened 3 years ago

liamdebeasi commented 3 years ago

Problem

On platforms such as iOS, web apps installed to the home screen have swipe gestures that allow users to navigate back and forth between pages. Many Single Page Apps (SPA) implement their own transitions or manage their own stack based navigation. As a result, the default swipe gesture gets in the way of these custom solutions.

When using webviews like WKWebView directly, developers can disable this swipe gesture functionality, but it is not currently possible to do the same with web apps installed to the home screen. This is not limited to iOS as I believe newer versions of Android implement certain platform navigation gestures as well.

Right now developers can use window.history.replaceState() to navigate without this built-in swipe gesture, but it tends to interfere with custom page transitions and navigation stacks.

The attached video shows the current problem in an SPA installed to the home screen:

https://user-images.githubusercontent.com/2721089/112997236-ede0de80-913a-11eb-885a-c0baac5029cb.mp4

In this example, the app has a JS-driven swipe to go back gesture that involves the "Back" button transforming into the "People" title. Notice that the custom swipe gesture causes the tab bar to stay fixed as well. The video shows how easy it is to accidentally trigger the platform's built-in swipe to go back gesture. You can tell that the platform's built-in swipe gesture is being triggered because the tab bar transitions, and the "Back" button does not transform into the "People" title. Additionally, the platform's swipe back gesture causes the JS-driven swipe gesture to be triggered as well, resulting in an awkward UX.

Solution

My initial thought is to add a new option to touch-action. When a web app is installed to the home screen, using this feature would disable the built-in swipe gestures that are found on iOS/Android.

These swipe gestures would always be enabled in a browser environment, but could be disabled when running a web app from the home screen. The reason for this difference is some websites could potentially use this feature in malicious ways to make it harder to leave spam websites. They already do this by redirecting users several times and opening several alert dialogs in a row, so I think disabling the swipe gesture in a browser environment would make this problem even worse.

The one concern I have with using touch-action is the current options allow you to opt-in to particular behaviors. So touch-action: pinch-zoom enables multi-finger zooming of the page. Where the swipe back gesture is enabled by default on iOS, having a value that opts-out of this behavior may be confusing. Open to other suggestions as to how we can handle this though. 😄

Alternatives

I have seen some examples on Twitter and GitHub where developers are making use of the touchstart and touchmove events to prevent the swipe gesture from activating, but that approach seems brittle and likely to break at any time.

cc @graouts (We discussed this on the WebKit Slack a few months ago, and you asked me to cc you when I created this)

fantasai commented 3 years ago

This appears to be specced in https://www.w3.org/TR/pointerevents3/#the-touch-action-css-property whose GH repo is https://github.com/w3c/pointerevents/ ; would you like me to ask to transfer the issue, or did you want to raise this with the CSSWG?

liamdebeasi commented 3 years ago

If the issue could be transferred, that would be great! Apologies, I did not realize that pointer events repo existed.

fantasai commented 3 years ago

Neither did I. :) @svgeesus @xfq Do either of you have the ability to transfer this issue? I think it needs someone with permissions in both repos.

svgeesus commented 3 years ago

I just tried and I don't. I will need to get admin on that other repo first.

svgeesus commented 3 years ago

@plehegar you have admin on both groups, could you do the move?

xfq commented 3 years ago

Neither did I. :) @svgeesus @xfq Do either of you have the ability to transfer this issue? I think it needs someone with permissions in both repos.

Done.

lincolnthree commented 3 years ago

As a PWA and hybrid mobile app developer, I don't have much to offer on this issue other than, "Yes, 100%, we need this."

The inability to tame the browser's native transitions for installed websites is one of the biggest ways in which PWAs break the "third wall" and reveal their true nature to users. It screams "This is a website!" when you swipe back and the whole app shudders backwards in strange ways, like the screen sliding off to the right on iOS when the app's native transition wants to be a fade out/down, etc.

Same on Android which implements the swipe back in several unique ways. None of which are generally used for app transitions.

NavidZ commented 3 years ago

We have an issue (#295) similar to this but Apple folks weren't happy with adding something like that.

lincolnthree commented 3 years ago

@NavidZ Sad. Well perhaps they'd be willing to compromise and at least fire an event that lets the application provide its own transition...

In my opinion, NOT doing this simply creates lots of awkward experiences. And does not really always result in working applications (or gestural controls). E.g. It's easy to get apps to totally break down when you go back in some critical places.

liamdebeasi commented 3 years ago

We have an issue (#295) similar to this but Apple folks weren't happy with adding something like that.

The scope of this feature seems to be a bit narrower than #295. Additionally, WKWebView already provides this functionality (https://developer.apple.com/documentation/webkit/wkwebview/1414995-allowsbackforwardnavigationgestu), so I would be interested in hearing the WebKit team's perspective on this.

lincolnthree commented 3 years ago

The scope of this feature seems to be a bit narrower than #295.

Agreed.

@liamdebeasi Ah interesting they provide the feature in WKWebView specifically. That's useful knowledge. Seems odd they would decline for home-screen installed apps. I'll decline to speculate more on that though.

nirjhar18 commented 3 years ago

We also have a massive Ionic Web app and we are interested in this feature.

lincolnthree commented 8 months ago

Still need this!

evertheylen commented 7 months ago

If I could add something, it would already be a big step forward if the browser tells the website whether it already animated the navigation action. The problem I'm facing (for example, in Safari), is the user drags from the left, Safari animates it, the popstate event triggers and my webapp animates the navigation again. It's a very jarring experience for the user.

It's just a simple idea, as I can imagine browsers could decide to not respect a setting to disable gestures because of abuse. (Similarly, AFAIK you also can't prevent/disable navigation itself).