1183054 - Cache web manifest files

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::System::Browser Chrome, defect, P3)

Description

[Guillaume Marty [:gmarty]]

We're already caching the icons. Caching the web manifest files should be done too.

I checked on a device and it seems that the HTTP cache directives (e.g. Cache-Control: max-age=xxx) are not honoured by the app. This may be due to XHR used to download the file. So maybe we need to implement a cache system at the Gaia level, in a datastore for example.

Comment 1

[Ben Francis [:benfrancis]]

I think we should store site metadata in the sites store, and page metadata in the pages store. See https://etherpad.mozilla.org/places-web-service for some thoughts on this for the longer term.

In 2.5 we may re-use the existing bookmarks DataStore as the sites store, and the places DataStore as the pages store. An example site might look like:

{
  "name": "Foo",
  "origin": "http://foo.com",
  "start_url": "http://foo.com/index.html
  "scope": "http://foo.com/",
  "frecency": 1,
  "pinned": true,
  "manifest_url": "http://foo.com/foo.webmanifest",
  "manifest": {
    "name": "Foo App",
    "short_name": "Foo",
    "icons": [
      {
        "src": "http://foo.com/favicon.ico",
        "sizes": "64x64",
        "type": "image/png"
      }
    ],
    "display": "standalone",
    "orientation": "portrait",
    "theme_color": "#0000ff"
  }
}

We may need to adapt this a little to fit the existing bookmarks store in 2.5.

With regards to updating the manifest, the current draft of the W3C manifest spec says "By using the manifest URL, a user agent MAY periodically check if the contents of a manifest has been modified (e.g., by honoring HTTP cache directives associated with the manifest or by checking for updates after the web application has been launched)." [1].

However, this part of the spec is in the process of being revised because it assumes that the manifest URL will not change. Unfortunately because of some design decisions taken in the manifest spec, we can not assume that the manifest URL will not change.

This has been discussed in a thread on the W3C Github [2]. I discussed this with Jonas and my current thinking is that every time the start_url of the app is launched, we should look for an updated manifest (which is currently done by XHR, but will eventually need to be done using some new API which uses the context of the app, see bug 1169633). If the manifest URL linked from the start_url has changed, we should update the manifest URL for the site. If the cache of the manifest has expired (based on the HTTP cache headers, possibly with some upper limit), we should download a new manifest.

The above is mainly talking about pinned sites, but we may want to cache the manifests for all sites the user visits which have one (which I assume is what you were talking about), so that a) we don't have to download it every time and b) we can track the frecency of sites.

1. http://www.w3.org/TR/appmanifest/#updating
2. https://github.com/w3c/manifest/issues/384

Comment 2

[Ben Francis [:benfrancis]]

See also bug 1190388 which covers updating the manifest metadata for pinned apps.

We may also want to do some caching for manifests of non-pinned apps by storing app metadata in the sites (currently "bookmarks") DataStore for all sites with a manifest, alongside other data like site frecency. Caching manifests for non-pinned apps could be covered by this bug.

Comment 3

[BMO Automation]

Firefox OS is not being worked on