Infrequently Noted

Alex Russell on browsers, standards, and the process of progress.

Comments for Not The Post I Wanted To Be Writing...

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.

Sorry, one more thing :)

You shouldn't design anything based on how things are built "today". It should be based on what we think will be built and how, in the future.

Refer to the original WebView for an example.

Thanks for the response, Alex.

You mentioned:

"Very few sites were using display: "browser". This means that the change Jeremy objected to affects a minuscule number of sites (today)."

...but amongst that minuscule (to Google) number are two of my own progressive web apps: and

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" 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.

Hopefully that clarifies the issue for everyone else.

by alex at

Hey Jeremy,

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?


by alex at
Thanks Alex. I have a much better understanding now.

I'm pleased to hear that you're thinking about the URL bar and how to make that visible.

I like the sounds of a minimal-ui—something halfway between "let me see the URL" and "I'm back in a regular browser".
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.
by Max at
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: