I see 65 added the title and a menu up there (in lots of blog posts), did it also add the Android back arrow to the left side?

Here's a screenshot of where the back arrow should be, and where it's currently present for Android apps.

Deleted: PlayStore ChromeOS.png 404 KB

	PlayStore ChromeOS.png 404 KB View Download

Our interpretation of the spec is that apps that specify display as 'standalone' should have as little browser UX as possible and that they should implement the back button themselves. If an app wants more of the browser UI, they should use 'minimal-ui'.

That said, we are exploring adding an option to the manifest that would allow websites to specify what browser features they would like e.g. back arrow.

Is there any way for a site to know how much browser UI is available to the user?

Kind of. They can use media queries to find out if they are in browser mode or standalone mode.

ortuno@ Since I can right click and choose "Back", and Alt+Left and go back, it seems strange to hide the back arrow that all Android apps get for PWAs. I understand that the spec is vague here, but it doesn't feel like it should require a new manifest value since the window still does have Chrome and that Chrome has a bunch of buttons and even the threedot menu in it.

Why should the window have the threedot menu but not the back arrow that Android apps have? Similarly on Android devices PWAs in standalone don't hide the system back arrow even though android apps can technically do that too (ex. games do that, but PWAs don't).

I think the argument goes that the back button is part of the system UI in Android and therefore we leave it there. The back button is not part of the system UI on desktop, so we don't go out of our way to show one.

I'm not saying that we shouldn't have one, just explaining the rationale that lead us here. There is a bug opened in the spec[1] and I believe mgiuca is working on a proposal on how to fix this.

[1] https://github.com/w3c/manifest/issues/673

From my perspective, I want PWAs to have as much control as possible (within reason; e.g., security mandates that we show the origin) over the title bar, when in installed app mode. As a first approximation, "display: standalone" means they are asking for as little UI as possible, so we do not show a back button.

> I understand that the spec is vague here, but it doesn't feel like it should
> require a new manifest value since the window still does have Chrome and that
> Chrome has a bunch of buttons and even the threedot menu in it.

The three-dot menu is the only concession that we made to the default title bar from the native OS, to give access to security information and other useful features. We don't want to clutter the title bar with redundant navigation controls unless the site requests it.

(I say "redundant" because the site asking for display: standalone *should* be designed with a built-in back button. If we slap a back button on these properly designed PWAs, we risk showing a redundant back button right above the in-client one. See Twitter Lite: https://www.reddit.com/r/Windows10/comments/87qcw8/twitter_pwa_double_back_button/.)

Having said that, I think we'll be showing a back button by default, for compatibility with MS. But I want to give an option for developers to disable the back button.

> Why should the window have the threedot menu but not the back arrow that
> Android apps have? Similarly on Android devices PWAs in standalone don't hide
> the system back arrow even though android apps can technically do that too (ex.
> games do that, but PWAs don't).

I can't speak for why Chrome OS doesn't hide the back button for Android apps when the app asks for it to be hidden. We want to give developers those controls.

Keeping this bug open for the implementation of new Back button controls.