+Owen for appiness thoughts. What's the desired behavior? I tend to agree with the bug.

Hmm yes, it sounds like this is a bug with our ChromeOS implementation somehow.

cc a few folk

On the scale of priorities I think we have other things to focus on right now, but I will chat to the team about setting up a launch hotlist so we can keep track of issues like this.

We do have a launch hotlist spreadsheet.

IMHO this is working as intended. Moving forward, we will only install sites in a window if they list themselves as "standalone" in their manifest. Standalone apps are expected to provide their own navigation UI (not rely on browser back/forward), and we do not explicitly provide a back or forward button.

Therefore I don't think it's necessary to expose these controls through gestures either, and I would expect developers who are trying to build a native app experience to be annoyed if we override swiping behaviour in this context.

If we do minimal-ui (which provides more browser-like controls such as back/forward button) then I think we should implement this gesture for such sites.

I disagree that this is WAI. To me the back/forward gesture falls under the same category as the scrolling gesture. It is so common (specially on macOS and iOS) that it is expected to work by default. If PWAs don't want it they can easily disable it (granted this just launched):

https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/OqBNF2efmFA/3ByBUKyaCgAJ

#7:
1. We are talking about Chrome OS specifically. I think we should consider each platform separately here (since this gesture isn't even on Windows and Linux IIRC).
2. "It is so common (specially on macOS and iOS) that it is expected to work by default." -- in what context? On the web, yes. But in an app, I don't know why that would be expected by default.

That is good info that it can be disabled though.

1. I'm not sure if need to differentiate between platforms. All of them have a variation of the gesture. On Windows machines with touchscreens, you can swipe to go back. Edge supports gestures as well[1] (though it's unclear if it's only for touchscreens or if it includes touchpads as well). This flag[1] seems to indicate this is also a feature on Linux[2].

2. If we are talking about any platform then on macOS[3] and iOS[4] the gesture is pretty common. Not that it matters much in the context of Apps but there are at least two million back navigations initiated by gesture on Chrome OS[5]. I think it's fair to assume this is something users expect to be able to do.

I'm not sure why it wouldn't be expected for Desktop PWAs. Many apps will be multi page apps and the gesture to move between these pages would be expected IMO. If an app is a single page app then they can easily disable the gesture, which they have to do anyway for the web.

[1] https://twitter.com/tfwboredom/status/727865594696077313
[2] chrome://flags/#overscroll-history-navigation
[3] http://osxdaily.com/2012/10/28/use-gestures-to-go-back-forward-in-many-os-x-apps/
[4] http://osxdaily.com/2013/11/27/use-swipe-gesture-to-go-back-ios/
[5] https://uma.googleplex.com/p/chrome/histograms/?endDate=20171003&dayCount=1&histograms=Overscroll.Navigated3&fixupData=true&showMax=true&filters=platform%2Ceq%2CC%2Cisofficial%2Ceq%2CTrue&implicitFilters=isofficial

glad to see some action happening on this bug!
FWIW, I understand your comments, but some of them are not quite in line with what I was having gripes with.  

>we will only install sites in a window if they list themselves as "standalone" in their manifest
>developers who are trying to build a native app experience 

This is not about a developer trying to have native experience, it's me as an end user consciously wanting to put some random web site into its own window. I do this because I find it easier to get to it quickly if I can Alt-Tab to it as if was meant to be standalone thing than getting back to it from my (too many) open tabs. I know there's the workaround to open it in a new browser window from a bookmark, but I'm still tied to the browser. I can't as easily just open that one (in this case news) site from an entry in the shelf.

>This is not about a developer trying to have native experience, it's me as an end user consciously wanting to put some random web site into its own window.

This is exactly what I do as well, find it useful and especially for certain sites where I want a little more vertical space without the toolbars present. Lack of swipe gestures just seems abnormal.

Others too are noticing: https://www.reddit.com/r/chromeos/comments/8btxhp/how_to_swipe_backforward_in_add_to_shelf_websites/

>Moving forward, we will only install sites in a window if they list themselves as "standalone"

I really hope this isn't suggesting I won't be able to add arbitrary sites to the shelf in future. *Everything* I use frequently is like this as I think it's by far the most efficient way to use ChromeOS and mimics the workflow of a typical desktop OS (chromeless apps, taskbar and alt-tabbing). To be quite honest, I find it quite bizarre the OS doesn't promote this workflow as standard and seems to push people into using it more like a browser with tabs and bookmarks (as soon as I turn my Chromebook on it shoves a pointless empty tab in my face as if I'm supposed to type 'gmail.com' in the bar to read my email). Everyone I know who has a Chromebook uses it like a web browser with a constant jumble of tabs and an almost empty taskbar. As it stands, ChromeOS is a confused mix of two paradigms - apps+taskbar VS bookmarks+tabs, with the latter being the more dominant (and imo, far less efficient) of the two. The web is a collection of frequently used apps (Gmail, Photos, Amazon) and static documents. Just like a desktop OS is a collection of native apps (Outlook, Photoshop) and documents (Excel docs, PDFs etc). Why are tabs even necessary in ChromeOS? It's like having 2 taskbars (3 if you throw a bookmarks bar into the mix, like most people do). Why can't 'documents' be gathered on the taskbar like Windows does with Word/Excel/whatever documents?  

Sites don't need a manifest or anything special to behave mostly like an app with the expected gestures. If used a certain way, you can make a Chromebook almost indistinguishable from a desktop OS like Windows; you just have to kinda go against the grain to set it up this way. Having to right click > go back instead of swiping is a real pain.

Apologies for the lengthy post. I love ChromeOS, but if I'm forced to use it like a browser running in a pointless, outer shell of an OS with tabs and bookmarks then that's going to kill the appeal of the platform completely.

Consider the touchpad on Chrome OS devices as the Navigation Bar on Android devices. For users, they are the most easy to reach places on devices, so it's good use them for navigation. There are three buttons on Android's Navigation Bar:
1) Overview button. We have corresponding three-finger up touchpad gesture on Chrome OS.
2) Home button. We don't have widgets on Desktop yet, so maybe there is no need in a corresponding gesture. But Chrome OS tablets are here, so maybe widgets are coming. Three-finger down gesture may be a good option.
3) Back button. I use it a lot on Android. It's cross-app consistent and the most handy way to go back. I'm really missing that button on iOS. Moreover, PWA are just sites on steroids. They use the same url navigation as other sites, so it's native for them to rely on browser's back/forward actions.

PS The alt+left(right)Arrow keyboard shortcuts work for "windowed" sites.

On further thought about this I think both objectives could be met. This is in reference to ChromeOS.

1) Continue to allow users to Add to shelf and open in window with normal two finger swipe gestures still enabled (just like alt+left/right are still enabled). This continues to give those of us who want to open certain sites/pages in their own windows that continued ability without losing helpful navigation abilities.
2) For developers trying to build web-apps with different navigation methods, allow the manifest to specify disabling of native navigation methods like alt+left or two finger swipe gestures. This gives full control to the developer, if the developer wants to keep the familiar back/forward/refresh methods they can, if they need to implement different they can.

I believe this would provide the best of all worlds and gives more control and flexibility to both the end users and the developers.

Any updates on this? I'm attempting to use cooking.nytimes.com as a new window pinned on the shelf (on Pixelbook), and it's nearly impossible to navigate without forward/backward gesture controls in tablet mode. If I open it as a tab in the Chrome browser and then set it to full screen, the gestures work fine. Definitely an annoying UI quirk.