1114631 - [parity] Detect "web app capable" sites using meta mobile-web-app-capable or meta application-name

Status: RESOLVED INCOMPLETE

(Firefox for Android Graveyard :: Web Apps (PWAs), enhancement)

Description

[nemo]

This is a request for better handling of web app capable sites, in a similar fashion to iOS.
http://w3c-webmob.github.io/installable-webapps/
notes that there is:
<meta name="mobile-web-app-capable" content="yes"> added by chrome to mirror
<meta name="apple-mobile-web-app-capable" content="yes">

Right now, if either one of those exists, and "Add to Homescreen" is selected in Chrome For Android, the page is handled separately.
When the icon is touched on the homescreen, a new process is launched that shows up in the Android app list as "Web Application"
It can be killed off by swiping, and has no url bar.  Pretty much acts as an app.

This behaviour is awfully similar to what has existed for quite some time in iOS, although iOS also adds that rather nice little prominent add button to make adding easier to discover.

This is pretty sweet, since a simple web app can be created just by slapping in a cache.manifest and a meta, and getting pretty good behaviour on Android and iOS these days.

I'd like to request that Firefox for Android, and ideally, FxOS, handle this the same way.
Possibly also detecting:
<meta name="application-name" name="My App"> 
which according to the link above is an HTML5 standard meta that should only be on an application capable web page, so seems like a good trigger.

Right now, FxOS does not treat a page added this way as an app, nor does Firefox for Android.  They are more like bookmarks.  FxOS does hide the url bar, but includes another bar apparently to help the user leave the app (regardless of whether the user is on the site/page in cache.manifest or not), which does not exist on normal apps.  


p.s.  Chrome also makes the icon nicely rounded, which fits in better with the rest of the app icons on Android.

Comment 1

[nemo]

So, just as an example.
http://0hn0.com/
Hit the hacker news frontpage.  In order to add it as an "App" to my Nexus 5, had to fire up Chrome.

They only use: 
    <meta name="apple-mobile-web-app-capable" content="yes"/>

But it appears Chrome detects that just fine, to make a "fullscreen" app, and a nicely rounded app icon.

Comment 2

[Bill Walker [:bwalker] [@wfwalker]]

It seems to be we could detect that meta tag and decide to invoke mozApps.install() to install that page as an app, we'd need to synthesize an app manifest.

Comment 3

[Ben Francis [:benfrancis]]

I would strongly suggest that we do not support the mobile-web-app-capable meta tag, particularly the apple prefixed version.

The Chrome documentation [1] says that this is only recommended for Chrome prior to version M39, from M39 the new W3C web app manifest is the recommended way for developers to do this.

  "New in Chrome M39, you can define the metadata associated with your web application in a JSON-based manifest"

They also support the apple-prefixed version, but warn that they will stop supporting that in a future release.

  "Chrome will also allow web apps to launch in "App mode" if they embed a meta tag using the "apple-mobile-web-app-capable" name. Chrome will stop supporting this usage in an upcoming release. Chrome currently shows a deprecation warning in the Developer Tools’ console log when it detects a page with only the "apple-mobile-web-app-capable" meta tag."

Let's not add to this mess, but instead support the web manifest standard which is expected to become a W3C Candidate Recommendation soon (I'm working on implementing this right now). Let's add support for W3C web app manifest to the Marketplace and allow any browser to use the Marketplace to find cross-platform web apps which they can launch instantly.


I do think use of the "application-name" meta tag is more acceptable because this is more of a standard, we actually already use it in the add to homescreen dialog in the Firefox OS browser as a title for homescreen bookmarks. But it does raise the question - what is the scope of the application which is being named? We can only really safely infer that the current page is definitely part of the named app, not any other pages you could navigate to from that page. We certainly can't infer that the web app doesn't need a back button.

The W3C web app manifest has a "scope" property which defines the URL scope to which the manifest (and therefore the app name and display mode) applies. Installing the app should register the app as managing that URL scope. This allows deep linking into the app and should throw you out of the app when you navigate outside of its scope so you don't get stranded on another web site without a back button.

I don't think there's enough information in a web page to infer the scope of the app or a suitable display mode and therefore synthesising a manifest is likely to create a bad user experience.

We could perhaps allow bookmarking or "pinning" a single page of a web site which hides the URL bar for that one page, but we'd have to show the URL bar again as soon as you navigate away from that URL.

1. https://developer.chrome.com/multidevice/android/installtohomescreen

Comment 4

[Ben Francis [:benfrancis]]

(In reply to Ben Francis [:benfrancis] from comment #3)
> support the web manifest standard
> which is expected to become a W3C Candidate Recommendation soon (I'm working
> on implementing this right now).

(in Firefox OS, I would love to talk to someone about adding support in Firefox for Android as well).

Comment 5

[nemo]

That "stranded on another site without a back button" has come up before when I experimented w/ getting similar results for web apps in FxOS as in iOS and Android.
Would like to note that this hasn't ever been a problem with users on those OSes that I can see. After all, apps embed web views allll the time and those can easily have links to other sites.  
If the app doesn't manage this properly, then it is the app's problem.  Since there is no browser chrome and they launched it from an app icon, I think the user considers this simply an app bug.  
Shame on the app for not having some return home button.  Simple fix, close the app. That's what the big round button on iOS and the arrow button on android are for ☺.  
It would be nice to be able to eliminate that annoying menu on FxOS intended to prevent this.  I found that requesting fullscreen mode on FxOS helped avoid this, but unfortunately that requires user interaction to enable, and required detecting FxOS too.

The "scope" of the application seems maybe to be over thinking this?  If the page has a cache manifest, and an application name, then it is an installable app.   How you browse from it is up to you, see above ☺

As for not supporting the apple tag, that would mess up thinks like that oh no app I linked to, but, eh, that's their problem. Someone can always send them a pull request and an evang bug can be filed.

I at least quite happily put the whole mess of current web app metas in my stuff.  That is:
<html lang="en" manifest="cache.manifest"><head>
<meta name="viewport" content="width=device-width, initial-scalable=1.0">
<meta name="mobile-web-app-capable" content="yes">
<meta name="apple-mobile-web-app-capable" content="yes">
<meta name="apple-mobile-web-app-status-bar-style" content="black">
<meta name="msapplication-TileImage" content="images/msIcon.png">
<meta name="msapplication-TileColor" content="#fcc">
<link rel="apple-touch-icon" href="images/Icon.png">
<link rel="icon" href="images/Icon.png">
<meta name="application-name" content="App Name">

Just as a sample...

Comment 6

[Ben Francis [:benfrancis]]

(In reply to nemo from comment #5)
> That "stranded on another site without a back button" has come up before
> when I experimented w/ getting similar results for web apps in FxOS as in
> iOS and Android.

This is a big problem for web apps everywhere. Bookmarking a page, opening that page in a browsing context with no URL bar and then assuming any URL you navigate to in that browsing context is part of the same "app" is fundamentally flawed, the web just doesn't work like that. It's not just the responsibility of the app developer, it's also the responsibility of the user agent to make sure hyperlinks do the right thing. It's also crazy that you can't deep link into a web app.

The "scope" property in the W3C web app manifest specification finally helps solve both of these problems and directly addresses deep linking.

> Would like to note that this hasn't ever been a problem with users on those
> OSes that I can see.

I would hypothesise that it has significantly contributed to the perception that web apps are lower quality than "native" apps.

> It would be nice to be able to eliminate that annoying menu on FxOS intended
> to prevent this.

I'm not sure which menu you mean?

I understand the desire to add mobile optimised web sites as a type of content in the Marketplace to show the full extent of what the web has to offer, but I don't think we can magically turn web sites into "apps" without creating a bad user experience which further reflects badly on the web.

If they're actually just web sites, let's be honest about that and open them with full browser chrome.

> <html lang="en" manifest="cache.manifest"><head>
> <meta name="viewport" content="width=device-width, initial-scalable=1.0">
> <meta name="mobile-web-app-capable" content="yes">
> <meta name="apple-mobile-web-app-capable" content="yes">
> <meta name="apple-mobile-web-app-status-bar-style" content="black">
> <meta name="msapplication-TileImage" content="images/msIcon.png">
> <meta name="msapplication-TileColor" content="#fcc">
> <link rel="apple-touch-icon" href="images/Icon.png">
> <link rel="icon" href="images/Icon.png">
> <meta name="application-name" content="App Name">

Uh, yeah :/

You should be able to replace most of that with:

  <link rel="manifest" href="manifest.json">

This will work in Chrome on Android, we should add support in Firefox and evangelise it to Apple and Microsoft who have both already expressed an interest.

Comment 7

[nemo]

Heh, well, that does mean "Doesn't work in anything but Firefox" right now.  Plus. One more manifest to maintain. Wheeeeee.
I guess I'll add that to my apps if that's the only way to get Firefox on Android/FxOS to behave, but... It'd be nice if it also supported these metas.  Thus this bug.
In the interim, having the tags there isn't hurting anything.

WRT FxOS, I mean if I have a web "app" flagged as above, FxOS insists on adding its own menu out of the fear that somehow I'll get "trapped" somewhere.
Something that does NOT happen if it is an "official" FxOS app with the magic JSON you mentioned (or if I request fullscreen using HTML5, but that requires being triggered with a touch event and is a poor user experience).

Somehow, a site that IDs itself as an app gets treated as website in Firefox rather than as an application also accessible from the web, something iOS and Chrome on Android manage to do just fine.

Comment 8

[nemo]

And, I'd like to note, while I'm fine with adding yet another manifest format, if pressed (although haven't bothered yet) that's quite another matter from you guys supporting all the existing web apps, like the one I posted an example of.

Unless the fix is Evang bugs everywhere?
Personally, I don't see why honouring the metas is such a big deal, so hopefully you'll consider it.

Comment 9

[Ben Francis [:benfrancis]]

(In reply to nemo from comment #7)
> Heh, well, that does mean "Doesn't work in anything but Firefox" right now.

Actually it means "doesn't work in anything but Chrome for Android" right now :(

> Plus. One more manifest to maintain. Wheeeeee.

I know, I hear you. But this is the first time we've actually had a W3C spec that multiple vendors agree on. I'm hopeful that this manifest will replace many of the others.

> I guess I'll add that to my apps if that's the only way to get Firefox on
> Android/FxOS to behave,

Actually currently you need to use an "Open Web App" manifest for Firefox or Firefox OS to hide the URL bar, and have users install the app from the Marketplace or with an install button in your app. Hopefully soon this will no longer be the case, and we will support the W3C web app manifest in all versions of Firefox.

> WRT FxOS, I mean if I have a web "app" flagged as above, FxOS insists on
> adding its own menu out of the fear that somehow I'll get "trapped"
> somewhere.

Yeah that's just a browser window with a URL bar, it isn't adding anything, it just isn't taking any notice of the sea of proprietary meta tags.

> Somehow, a site that IDs itself as an app gets treated as website in Firefox
> rather than as an application also accessible from the web, something iOS
> and Chrome on Android manage to do just fine.

Unfortunately they do this by creating a proprietary solution for each platform, which is how we ended up in this mess in the first place :(

(In reply to nemo from comment #8)
> And, I'd like to note, while I'm fine with adding yet another manifest
> format, if pressed (although haven't bothered yet) that's quite another
> matter from you guys supporting all the existing web apps, like the one I
> posted an example of.

You're absolutely right, and we could get access to a lot more "web apps" overnight if we just supported all of the proprietary meta tags. I just hope we don't do that, because the web loses out in the long run, as it would if we adopted lots of other vendor prefixed proprietary features from other browsers.

> Personally, I don't see why honouring the metas is such a big deal, so
> hopefully you'll consider it.

Respectively I hope we don't, though we have already added support for apple-touch-icon so who knows!

Comment 10

[nemo]

Well, as I see it, cache manifests *are* a spec, so right now the FF JSON is the proprietary one, even if it is more featureful.

2 of the metas above are unprefixed and proposed as specs.  Firefox using them to recognise web apps would not be unusual, and would allow it to reach parity with other apps.

The only question would be supporting the apple one for naughty apps like the oh no one I mentioned.
However, contacting them and asking "hey, please add an unprefixed version of a meta tag you have already to support firefox properly" seems way less of an issue than "Hey, FxOS has this new manifest format. Mine incorporating it into your build process?"

Anyway. Probably no point in running around in circles on this.  Either you guys will add it, or you won't...
Places where I'm not using the FF JSON are currently not quite as nice in FF on Android or FxOS, but that's still a pretty tiny market share.
I can wait to see how it all shakes out.
Right now I had to muck around more working around chrome and safari layout bugs, since that's what the majority of mobile is...

Comment 11

[BMO Automation]

We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.