Sharing scope with manifests #137

annevk · 2013-12-18T16:15:04Z

If we have manifests, it would be great if they had the same scope as their app worker. How do we do that?

annevk · 2013-12-18T16:17:28Z

In particular, if the scope is not going to be origin, we need some way of making sure all kinds of APIs know what the scope is for a given URL (and therefore what manifest, worker, etc. apply to it).

slightlyoff · 2013-12-28T02:06:29Z

here's an example manifest in a format I've made up:

{
  "name": "Acme Example",
  "description": "...",
  "developer": {
    "name": "Acme Corp.",
    "url": "http://acme.com/example"
  }
  "icons": { "128": "/example/assets/images/v1/icon_128.png", ... },
  "launch_path": "http://acme.com/example",
  "service_worker": {
    "scope": "/example/*",
    "url": "http://acme.com/example/controller.js"
  },
  "content_security_policy":
      "default-src 'self'; sandbox; ...",
  "requested_permissions": {
      "alarms": "synchronize data in the background",
      "push": "notify you of important product announcements",
      "...", "..."
  },
}

The scope here mirrors what the app itself would register:

// http://acme.com/example/app.manifest
navigator.registerServiceWorker("/example*", "/example/controller.js").then(..., ...);

And here's a page that both registers an SW and includes a reference to the manifest:

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="manifest" content="/example/app.manifest">
    <script>
      navigator.registerServiceWorker("/example*", "/example/assets/v1/ctrl.js").then(...);
    </script>
  </head>
  <body>...</body>
</html>

Now, of course, these could have different registrations. The SW that the page registers could include an SW for a different scope, or it could point to a different URL. The question is what to do in the various scenarios.

Manifest omits SW registration: Disallowed. No apps without SWs.
Page omits SW registration: No worries. Only one SW in play (the manifest SW).
Page includes different SW but at the same scope as Manifest: last registration wins. This might create a fight and it might be hard to debug. Worst case here is if the SW serves a document which includes a different registration as the one that served it. Assuming the same scope (e.g., "/example/*"), this will kick off a request for the "new" SW and make it the SW-in-waiting. For maximum SW-thrashing, we could assume that the document calls e.replace() in oninstall. While bad, I don't think this is any worse than what would have happened if the original SW registration and SW-served pages conflicted.
Page includes same SW but at different scope to Manifest: No worries. Longest-prefix-match ensures that each registration will be entirely independent. If the manifest registers for /example* and the initial page registers for /*, navigations to the example app will be sent to the manifest-registered-and-managed version.
Page includes same SW/scope as Manifest: No-op. The SW will be checked and will be found to be byte-for-byte the same with the existing SW and no update/install will be performed.

What becomes really interesting here is the question of alternative browsing contexts. It's possible to imagine that UAs that do something with the manifest will launch content via them in a separate browsing content (separate storage partition, profile, etc.). In that case, identical registrations will cause separate installs -- however they wouldn't necessarily be visible to each other, reducing confusion. I think this is perhaps the best solution for UAs when "keeping" apps they discover to have manifests.

Does that cover all the questions you had, @annevk & @marcoscaceres?

annevk · 2014-01-06T14:23:55Z

Well, it's an idea. I'm not sure I like it though as it has race conditions and the potential for trivial errors. I would prefer something that was more centralized.

benfrancis · 2014-03-14T18:05:43Z

Does it even make sense for manifests and ServiceWorkers to share the same scope? What if you want mutliple ServiceWorkers for one app, or even multiple apps (on the same origin) which share the same ServiceWorker? How would you define the scope of an app which has no ServiceWorkers?

I can see it makes sense to enumerate ServiceWorkers in the manifest so that they can be registered when the app is bookmarked/installed, and the manifest scope could work in much the same way as ServiceWorker scope, but I'm not sure they can be the same thing?

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Sharing scope with manifests #137

Sharing scope with manifests #137

annevk commented Dec 18, 2013

annevk commented Dec 18, 2013

slightlyoff commented Dec 28, 2013

annevk commented Jan 6, 2014

benfrancis commented Mar 14, 2014

annevk commented Mar 17, 2014

Sharing scope with manifests #137

Sharing scope with manifests #137

Comments

annevk commented Dec 18, 2013

annevk commented Dec 18, 2013

slightlyoff commented Dec 28, 2013

annevk commented Jan 6, 2014

benfrancis commented Mar 14, 2014

annevk commented Mar 17, 2014