Display mode "standalone" inconsistently handled by browsers
Closed this issue · 13 comments
For display mode "standalone", the spec has the following to say (emphasis mine):
"Opens the web application to look and feel like a standalone native application. This can include the application having a different window, its own icon in the application launcher, etc. In this mode, the user agent will exclude standard browser UI elements such as an URL bar, but can include other system UI elements such as a status bar and/or system back button."
Now of course Edge and Chrome OS handle this differently on desktop, where Edge would show a back button (courtesy of @boyofgreen), and Chrome OS wouldn't show a back button (courtesy of @kenchris).
On mobile, the general idea seems to be to not show any browser UI at all, which causes navigation issues for devices without a dedicated system ("hardware") back button as on Android, for example in iOS (see the screenshot, courtesy of @firtman).
The spec should probably add more guidance as to when to show a back button in "standalone" mode and when not; basing the decision on the presence or absence of a system ("hardware") back button seems like a reasonable default.
Keep in mind that Chrome OS usually doesn't have a back button when connected to external keyboard
⬆️ Which strengthens the point made in the issue.
What is the motivation behind needing more guidance in the spec for when a back button is shown?
As a general principle, specs tend to be less prescriptive regarding what browser UI looks like to give vendors flexibility in designing the UI which fits their needs.
The reason is that browsers inconsistently implement standalone (which is fully spec-compliant due to the blurriness).
This leads to platforms that don't have a system-level back button like iOS to trap users in PWAs that don't implement app-level navigation.
iOS has a global exit command (the Home button), so users will never be trapped in a PWA. They can always exit with Home.
More generally, standalone mode explicitly says Opens the web application to look and feel like a standalone native application. It's not the role of the manifest spec to enforce that implementing platforms break their own UX norms. iOS never shows a back button in system-level UI: native applications must handle their own back and forward, so a PWA that works well on that platform should be reasonably expected to do the same. It's the developer's prerogative to implement their app in a way that fits the native application model on each platform.
Trapped as in having no way to go back and needing to exit to the home screen to start from scratch.
The fact that Microsoft have added the back button shows that they saw the need to address this problem by fighting the symptoms, and these are developers testing on Android only and forgetting other platforms with less affordances.
I agree that apps shouldn't violate the particular platform's UX norms, but de facto they do by not testing on all platforms.
Maybe the spec text should then at least make this point clearer, if you feel like leaving the system back button a can feature.
I'm fairly sure Microsoft/Edge has a back button on PWAs because that's a system norm - all UWP apps need to handle back buttons since they're meant to run on devices with and without hardware back buttons, so PWAs are just fitting in (see https://blogs.msdn.microsoft.com/cdndevs/2015/08/14/uwp-back-button-is-everywhere/ and https://docs.microsoft.com/en-us/windows/uwp/design/basics/navigation-history-and-backwards-navigation).
If the possibility of different platforms having different browser UI is something that developers haven't yet picked up, I'm also not sure extra text in the manifest spec is going to help. :)
@tomayac if you look in the video at https://youtu.be/6fb-t9ffDvo?t=762
I'm not sure why Microsoft is not opening the app actually in full screen. For games, it makes a lot of sense to open directly in fullscreen.
Here a problem arises. For Chrome, full screen is properly interpreted as taking up entire display area, which follows the spec. For Microsoft, it takes up only the entire area of the window effectively becoming standalone.
If my app manages the back button its self, I would not want the OS to manage it.
To implement the correct behavior across both browsers, when I detect the useragent as Chrome, in the PWA, I'll have to send manifest with the display property as standalone. When the useragent is Edge, I'd have to send another version of the manifest that has display property as fullscreen to give an expected experience.
Can we not make the spec strict so that if a developer says something the browser actually has to follow it, or at-least offer a strict version such as fullscreen-strict or standalone-strict. This hacky way I am having to do to provide a consistent with Edge is going to become a maintenance nightmare.
And maybe we should document the default behavior for all 3 major browsers for all properties (Chrome, Edge and Safari) because even I am confused despite reading all the documentation.
We had a chat about this yesterday (internal to Google) and I've been discussing an internal proposal to do basically two things:
- Give developers explicit control over whether a back button, and other UI elements, are shown (rather than just leaving it up to the UA and the vague descriptions of "standalone" and "minimal-ui" in the spec), and
- Give developers a way to query whether the UA is currently showing a back button (either UA-provided, system-provided, or in hardware).
The main problem I am trying to solve is this "double back button" as shown here (actual screenshot from the Twitter PWA in the Microsoft Store):
This is due to the app not knowing whether the system is providing a button. I don't think we really need to give developers explicit control over whether there's a back button --- certainly we can't give absolute control because the UA can always decide to add a back button, or may be forced to by having a system or hardware one. I think it's quite sufficient to merely tell developers whether there is a back button. Thus, I'm going to focus on number 2 for the time being (will file a separate bug).
I just saw this existed and wanted to throw in a +1 for this for Twitter. @aarongustafson and I had talked about this too recently and thought it would help.
@tomayac, I'm still a bit confused what I should change this to. As @dominickng pointed out, we can't really be too prescriptive here, as we are encroaching on platform UI conventions, and the display modes are really only here as a general guide.
If possible, would could you propose what you'd like to see it say instead? We can maybe iterate a bit more from there.
If possible, would could you propose what you'd like to see it say instead? We can maybe iterate a bit more from there.
Opens the web application to look and feel like a standalone
<del>native</del><ins>platform</ins> application. This can
include the application having a different window, its own icon
in the application launcher, etc. In this mode, the user agent will
exclude standard browser UI elements such as an URL bar, but
can include other system UI elements such as a status bar<del>
and/or system</del><ins>, but there should be no assumption of
navigation UI elements like</ins> back button<ins>s</ins>.The double back button is no longer shown for Microsoft Store apps, at least in Windows 11:
This seems to have been the original reason for this issue, so I suggest closing it.