Add option to disable built-in navigation gestures

[liamdebeasi]

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. Some 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:

stgb-pwa.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

Add an option to the Web App Manifest that allows developers to disable/enable the built-in gestures provided by an OS. This would allow the application to handle any gestures associated with navigating back/forward.

Alternatives

I previously proposed this as a feature for touch-action in CSS (w3c/pointerevents#358). However, since this is very specific to installed web apps I wanted to propose the feature here to see if it makes more sense for this feature to exist in the Web App Manifest.

[marcoscaceres]

Thanks @liamdebeasi. We will discuss your proposal when the editors next meet.

[danielehrhardt]

Thanks @liamdebeasi. We will discuss your proposal when the editors next meet.

What is the result?

[petermakeswebsites]

This is paramount to an app I'm developing and it seems very reasonable solution to implement, given that the user has already consented to installing the app and therefore should probably expect it to work like an app. It makes sense to have it in the manifest.

It would be very nice to override the default behaviour. In Android, to disable back navigation completely in PWA. In iOS, to disable back as well (but iOS also has the added animation that makes web apps look horrible). This proposed solution should be standard to give the web app developers total control over gestures in their app to make them behave as intuitively as possible for the user.

[aiddun]

@marcoscaceres, was this ever discussed by the committee?

[Merwan1010]

Anything new ?

[marcoscaceres]

I'm so sorry this fell off our radar. We just discussed it... which other gestures might need to be disabled? So, like back swipe from left and right of screen? And I guess pull to refresh maybe? What else?

[Merwan1010]

@marcoscaceres Thank you for your message.
That's all I can think of right now.

[liamdebeasi]

Thanks for the reply! The big one is the swipe left/right gestures. Pull to refresh is another one that would be good to disable. Ionic Framework implements its own pull to refresh effect.

[evertheylen]

On second thought this comment is a better fit for the pointerevents issue. Sorry for the noise!

Old comment

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).