Most “opens” of PWAs happen in tabs through normal navigation. This has multiple causes, including an inability (which we’ll resolve at some point) for Chrome to be able to open navigations to PWAs from external sources in non-browser mode.

Very few sites were using display: "browser". This means that the change Jeremy objected to affects a minuscule number of sites (today). Now, obviously, Jeremy could go and evangelize all PWA developers to use display: "browser", but that sort of seems misguided because…

It doesn’t solve the problem of URL access or Sharing for sites that chose a different mode (e.g. fullscreen, standalone, or minimal-ui).

That last point is the high-order bit for me. Like Jeremy, I’m agitated over the lack of access to URLs for PWAs launched in a more immersive mode. That seems to be the thing to be frustrated about if you care about URLs and sharing and it’s my concern too — so much so that our team prioritized fixing it this quarter. New UI and gestures are hard to get right which is why I’m excited that Owen and Rebecca have been looking into how to make URLs accessible to PWA users no matter what display mode they’re in. We’ll have more to show on this front soon.

We’re going to do something about this imminently because web developers who are building PWAs tend to forget about sharing. It’s been painful in our audits of partner apps to have to remind them to “build a share button” and then make sure it’s available on-screen in the right modes. It sucks to implement and it’s harder to use than a ubiquitous UI contract. At the same time, successful PWA developers are striving for UI consistency with the native platform their apps run on. They want their Web cake and the want to eat it like an App. The onus, then, is clearly on the browser to bring URL access back in ways that developers can’t defeat and can’t forget.

Which brings us to a final point that seems to have been lost: browsers can fix the real issue — sharing of PWAs and access to URLs — without anyone changing anything about their apps, and can do it out-of-band. Obviously, this is only true for browsers that support PWAs and have fast update cycles which, today, is all PWA-supporting browsers; namely Chrome, Opera, and Samsung Internet. The folks who work on these browsers — including myself — care as much as Jeremy does about the health and future of the web. I’m grateful to him for highlighting this issue and hope we can work together in the future to figure out ways to keep the best bits of the web healthy as PWAs become a common way to get back to sites users love.

9 Comments

You should mention that displaying a URL also improves security. Sharing is good, but it’s only half the story.

The ability to view the URL reduces the risk of phishing attacks which can lead to malicious activity in the background – installing malware, stealing personal credentials etc.

And then there’s the ability to see the URL which might provide insight to the suitability of content, which might not be appropropriate for the person accessing it – either because of their preference, age or location.

Chrome for mobile didn’t adopt the Google Safe Browser API until December 2015, so naturally we can’t make assumptions about Google’s intention to address security concerns from day 1.

I totally get why the majority of progressive web apps would choose standalone or even fullscreen, but then to extrapolate that out to all progressive web apps is a step too far.

I fear that, working at the scale that Google does, where real big data is readily obtainable, there’s a danger of dismissing edge cases for the perceived greater good. What appears to be a rounding error when you’re looking at overall numbers equates to real people down at the coalface.

It’s possible to balance the big-picture long-term goals (“we need a way for users to get at URLs in progressive web apps, regardless of the display property value”) with the “minuscule” short-term—but just as real—concerns (“why is my progressive web app being punished for using display: browser when it’s currently the only way to give users access to the URL?”).

You’ve got the big-picture view. You’ve always been good at having the big-picture view. But please don’t lose sight of the more immediate more mundane issues too.

Paul: we’ve had this discussion on Twitter, but to re-iterate here for the benefit of those who weren’t part of those conversations: everyone should understand that Progressive Web Apps always begin life inside a tab. That is to say that to get to a full-screen PWA experience a user has to:

Visit a site and interact with it a bunch

Agree to a prompt to add it to the homescreen

Launch it from that prompt

The site in question has to have been presented over TLS for any of this to happen, which means that it’s “really” example.com the user is talking to. If the site contains mixed content, the prompt isn’t show. If it starts to contain mixed-content later (while launched full-screen) or encounters a TLS error, a security indicator and the URL is shown, regardless of how it was launched.

Further, if the user navigates to a URL that’s on another origin, that navigation takes the user to another tab in the browser (with the default URL bar). At no point is the PWA allowed to present full-screen content for other origins that don’t wish to be presented by that origin (e.g., an iframe) and the security system is set up to ensure that the icon on the homescreen that you tap only gives you a full-screen experience to the extent that you’re actually viewing content from the site you installed the PWA from.

Thanks for responding. I take the point that access to the URL bar should be allowed for sites that want it. One option we’re considering here is a Chrome Custom Tab-alike UI for the minimal-ui treatment (among others). That’d get you the URL-bar (or similar) without much risk without putting it in the “sea of tabs”. Would that work for you?

Talking of not ignoring edge cases, there are a set of apps that have little or no interest in the URL. They are usually completely standalone and almost trivial in nature, and ports of apps that were packaged apps of some kind (eg crosswalk). Perhaps it would be appropriate to add a URL to the “help” page of the PWA of such an app, but the designers of these apps deemed it undesirable to constantly show the URL so that is how it should be.
I’m just saying that we should be careful not to go completely in the opposite direction. Some method of being able to query a PWA’s URL after it’s been added to homescreen, but not part of the apps ui, is the way to go, IMO. It should solve the issue of the user asking “where did I get this from?” whether that be due to curiosity or a desire to share the app with someone else.

How about when launched from the home screen browser, standalone and minimal-ui apps started scrolled down just enough to hide the URL bar? s
That gives a clear affordance for a URL, but could still give them the home screen icon. Scrolling up to get to the URL is an already natural gesture for any chrome android user. More with pictures at: