Summary

It is possible to mimic the browser UI swipe-to-nav animation and action with content using overscroll-behavior-x: none and basic event listeners.

Steps to Reproduce

• Navigate to this example.
• Click the Swipe to Nav Example link.
• Perform a two fingered gesture to the right to attempt to trigger a Swipe to Nav gesture.

Actual Results

The content "swipe-to-nav" is run and instead of navigating back to the start page, a unvisited target is loaded.

Note: I'm testing on mac, so I'm attempting to mimic the mac animation in the example.

Expected Results

The expected results are a bit ambiguous. The definition of overscroll-behavior with contain and none specifies that:

the element must not perform non-local boundary default actions such as scroll chaining or navigation

So we are following the spec, but perhaps there should be some indication to the user that we're not actually performing a navigation. For example, the swipe-to-nav animation could involve the browser chrome outside of the content area in some way to indicate a "real" navigation.

Prior Art

The current results are similar to what content can achieve with History.pushState with browser.navigation.requireUserInteraction=false (the current default - see bug 1645211). For example using the following steps:

• Navigate to this example.
• Click the pushState Example link.
• Click the Back button.

With browser.navigation.requireUserInteraction set to true, the unvisited target should not be the target of the navigation. The same behavior as the Swipe to Nav Example will be observed if browser.navigation.requireUserInteraction set to false.

Adding [:hiro] and [:dholbert] due to prior discussions.

Behavior in other browsers engines:
(1) Chromium matches our behavior for the Swipe-to-nav STR here; i.e. it's affected by the same issue.

(2) WebKit (epiphany on Linux, Safari on macOS) is sort-of unaffected. With Dan's STR, a full swipe does successfully navigate back to the start page (start.html). If I do a partial swipe (i.e. swipe partway, but then release or reverse directionality to let the page "snap back"), then I do end up at the injected splash page; but it's also clear that I haven't navigated back, due WebKit's visualization of the swipable-stacked-cards metaphor.

(In reply to Dan Robertson (:dlrobertson) from comment #0)

but perhaps there should be some indication to the user that we're not actually performing a navigation. For example, the swipe-to-nav animation could involve the browser chrome outside of the content area in some way to indicate a "real" navigation.

Yeah, showing some indication in the browser chrome would be a mitigation. Though, even now, the URL is changed in the URL bar in the browser chrome I don't think people does always watch it carefully. And it makes me realize that we shouldn't allow swipe-to-navigation in full screen state?

(In reply to Daniel Holbert [:dholbert] from comment #2)

(2) WebKit (epiphany on Linux, Safari on macOS) is sort-of unaffected. With Dan's STR, a full swipe does successfully navigate back to the start page (start.html). If I do a partial swipe (i.e. swipe partway, but then release or reverse directionality to let the page "snap back"), then I do end up at the injected splash page; but it's also clear that I haven't navigated back, due WebKit's visualization of the swipable-stacked-cards metaphor.

This is really interesting! It appears that they do not include navigation in the non-local boundary actions skipped when overscroll-behavior is set to contain or none . This definitely would make implementing something to mimic their swipe-to-nav pretty ineffective. However, I think it would make it difficult for web developers to create a custom (and legitimate) site internal swipe to nav. Note that this blog discusses how to block swipe to nav for Safari. I've verified that it works for the example, which makes me wonder if there is a way to implement the example with preventDefault and no use of overscroll-behavior.

(In reply to Hiroyuki Ikezoe (:hiro) from comment #3)

Yeah, showing some indication in the browser chrome would be a mitigation. Though, even now, the URL is changed in the URL bar in the browser chrome I don't think people does always watch it carefully.

This is a good point.

The severity field is not set for this bug.
:botond, could you have a look please?

For more information, please visit auto_nag documentation.

Marking as S3 for now, we can revise in the future based on any security rating.