In Firefox OS we would like to support the installation of web apps which use a manifest as defined by the "W3C Manifest for Web Application" specification [1] (an Editor's Draft at the time of writing). This meta bug is to track the work needed to support this manifest format, particularly for the use case of dynamically installing an app into the app registry from Gaia's system app in the "bookmark to homescreen" use case where a web page references a Web Manifest in a "manifest" link relation. 1. http://w3c.github.io/manifest/

Fabrice, I've been looking into your suggestion that bookmarking a page which specifies a Web Manifest URL in a manifest link relation might dynamically install an app into the app registry. When the user goes to bookmark a web page which has a Web Manifest, we could offer the user the option of adding the "app" to the homescreen rather than just bookmarking the page. The system app could listen for mozbrowsermanifestchange events to get the manifest URL, then call window.navigator.mozApps.install() with that URL to install the app. I'm not yet sure whether Gaia should get the manifest itself via XHR (WIP patch in bug 1003876), or Gecko should get it and parse it and then somehow expose a sanitised version to content (as per the discussion in bug 997779). But once we parse the manifest we could decide whether to install an app or just add a homescreen bookmark based on the displayMode specified in the manifest. We could just add a bookmark in the case of the "browser" display mode for example. Does this approach sound reasonable? If so, then I think we would need to add support for the Web Manifest MIME type and format to the apps API. Jonas suggested it could just be a case of internally translating from one format to the other.

It would be better to fetch the manifest only once. If this needs to be done in gaia to decide between bookmarking and installing, we could change mozApps.install() to accept the manifest itself as an optional parameter (we'll need something similar for packaged hosted apps anyway). On the other hand, in gecko we do content type checks (which I'm not opposed to remove) and then we verify that the manifest itself has the expected information. I'm not too worried about supporting this new manifest format alongside the current one. There's still the question whether we should expose a "translated" manifest to content or make it clear that it can get different formats, but that's manageable.

Fabrice, should I file bugs under this meta bug to add support for the "start_url", "icons", "orientation" and "display" properties to the Apps API? I'm not sure how much parsing of these properties needs to happen in the Apps API and how much is down to Gaia's window manager to interpret. I don't know whether you'd prefer to internally translate from Web Manifest to Open Web App Manifest format (e.g. start_url -> launch_path), or support them separately. Support for "short_name" is already being tracked in bug 1001861.

If I understand the Web Manifest spec correctly, start_url can only be same-origin with the "install" page. So we should be able to turn start_url into a launch_path (since launch_path can't be an absolute url and is resolved against the manifest url). Short term, this is the simplest solution. Longer term, we likely want to converge to the Web Manifest spec, but we'll need quite a lot of changes since there are many users of launch_path.

Core Graveyard / DOM: Apps is inactive. Closing all bugs in this component.