New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 865567 link

Starred by 2 users

Issue metadata

Status: Started
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 3
Type: Feature

Sign in to add a comment

Investigate enabling kOverscrollHistoryNavigation on Android

Project Member Reported by, Jul 19

Issue description

I find the kSimpleUi variant of the overscroll history navigation to be quite elegant on touch enabled Chrome clients, so I think it would be interesting to try porting it to Android and seeing how it feels.

+mohsen as the original author of the Aura version
+nickrad for Android PM awareness to not be scared of crazy things
+mdjones for the most awareness of our browser composited UI these days

Definitely P3, but just something I wanted to track.
Some quick notes for future me:
OnOverscrolled() provides both x and y overscroll, we can probably add another handler for tab switching, similar to what the class OverscrollRefresh is doing.

Android appears to have a widget for overscroll refresh that we use (that overscroll events eventually get piped to), it doesn't look like there is such a thing for side-swiping, but that seems like it wouldn't be that hard to implement (the layout is simple enough).
I wonder if we can reuse the aura UI for the side nav.  The existing Android refresh UI was implemented to be consistent with Android's pull to refresh, but no such concept exists for side swipe.
Status: Assigned (was: Available)
Assigning to jinsukkim@ to see if we can make this a reality.

Here was my super hacky prototype for this:

The problem is that it doesn't work on native pages like the NTP.  So, we will likely need to build a version that works across android widgets and composited UI.  We might want to always render in java, but maybe we can share the positioning and motion components with native.
Looks interesting! I guess is missing in the CL...? It could be a good starting point so I want to understand how it was done.
I believe HistoryNavLayout is an inner class in the larger swipe java class, so I "think" it should all be in there.
Should've scrolled down further. Thanks!
Status: Started (was: Assigned)
> I wonder if we can reuse the aura UI for the side nav.  The existing Android refresh UI was implemented to be consistent with Android's pull to refresh, but no such concept exists for side swipe.

It would be more desirable if the drawable (circle with back/forward arrow for side nav) is designed with same look-and-feel as the one used for tap-to-refresh on Android, rather than aura UI. Its side/tap-to-refresh UI look consistent. I think Clank keep them consistent as well.

Found it is in third_party/android/swiperefresh/ Maybe the new drawable should be added there?

I personally think the refresh one is too small for edge navigations.  I think the aura one is prominent enough to notice.

My thinking was to keep it consistent with desktop for now and then let UX iterate on it, but at least they approved the Aura one at some point in the past.

I think UX would actually prefer showing snapshots of the previous/next page on these edge gestures, but I think that raises even more complexity.

I think we still have to go through the whole launch process based on this, but my thinking was to get something behind a flag to allow us to play around with.  It would be fine to go with whatever is easiest to start and we can add onto it as we get more UX guidance.
Point taken. Let me put together what works easiest for me to get it started working then.

Details in UI (dimensions, color) may be different from Aura but trying give it same look-and-feel.
5.7 MB View Download
Components: Blink>Input
This has web platform implications, so please keep the input-dev team (/cc nzolghadr) in the loop on this.

I assume that, like for ChromeOS, 'overscroll-behavior:x contain' can be used by a site to preserve today's behavior, right? IMHO it's critical that (unlike Safari) we preserve Chrome's "content not chrome" philosophy of giving the web page primary control over how input over it's surface is handled.

Eg. For Google photos, user confusion about the effect of swiping forward/back is one of their top user complaints on iOS (since users generally can't distinguish between a swipe handled by the content, and one handled by the browser). I think chromium's approach is superior since it doesn't rely on the mere position of the swipe (near the edge or not) to change behavior, and allows sites to customize the behavior. But still, we can expect some amount of developer and user frustration whenever we change scroll behavior.

Thank Rick for your input. Yes Ted and I are aware of the issue you pointed out, and will make sure it is addressed (web page will have priority in handling the swipe event over the navigation).
Project Member

Comment 13 by, Nov 28

The following revision refers to this bug:

commit 459ee142e66050d41139f8d7f28ef3d9945bb98f
Author: Jinsuk Kim <>
Date: Wed Nov 28 06:27:31 2018

Android: Create a chrome://flags entry for gesture-nav

Creates a new entry in chrome://flags for gesture navigation
that will allow horizontal scroll gesture to navigate forward/backward.

Bug: 865567
Change-Id: Id35d8ad261e2f4a29e34c4b4a73eed04029ba643
Commit-Queue: Jinsuk Kim <>
Reviewed-by: Scott Violet <>
Reviewed-by: Ted Choc <>
Cr-Commit-Position: refs/heads/master@{#611577}

Just chiming in; wouldn't this break what Android users expect when they swipe from the left (an app drawer)?

I'll admit that I'm biased here because I have PWA's that use the "swipe in from left edge of screen" to show an app drawer on Android. Would hate if breaks because of this change.

Any chance that web developers can control whether this works through a Javascript call or meta tag or something?
I'll have to defer to rbyers@ for the best way for a PWA to disable this entirely, but the goal is to definitely defer to the site before we attempt to trigger any such accelerator.

For example, I don't see this ever working on because there is no concept of overscroll there.  I "hope" that enabling this wouldn't require anything from your site.  The goal would be that swipes from the left would open the drawer and if they did it again (and purposefully...might need to tweak the triggering from what Chrome OS has) then it would trigger this gesture.

If you have a ChromeOS device available, you might trying their existing behavior on your page (w/ devtools set to mobile viewport) which would be a good minimum bar for what we would expect.

But yes, we aim to make sure this doesn't prevent sites from building true app like experiences and this is targeting just the drive by web that would help people easily navigate.
Right, on ChromeOS today (which already has gesture navigation), sites with correctly implemented side-swipe gestures will not trigger the effect (i.e. either due to calling preventDefault on the touch events, use of CSS touch-action to disable horizontal panning, or use of CSS overscroll-behavior to disable horizontal overscroll effects).

The one remaining argument I've heard (eg. from the AMP team) against this is that it may still result in user confusion/frustration when a common gesture often has two very different semantics depending on the site you happen to be on (open drawer, or abandon all current state and go back).

I could imagine exploring some additional mitigations for this such as disabling the feature by default when running without browser chrome (i.e. as a PWA). Or maybe even gating horizontal overscroll on the presence of VERTICAL document viewport overflow - the idea being that "apps" tend to have content inside of a an app shell and so aren't scrollable vertically and users wouldn't expect swiping horizontally to go back/forward, while "documents" tend not to have app-like UI like drawers. But that would just be a heuristic.

Sign in to add a comment