Comments for Not The Post I Wanted To Be Writing...
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.
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: https://adactio.com and https://thesession.org
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.
Hopefully that clarifies the issue for everyone else.
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?
Regards
I'm pleased to hear that you're thinking about the URL bar and how to make that visible.
https://medium.com/@kevinmarks/progressive-web-apps-and-url-bars-374f6bbdaf2f#.9hikqafg3
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.