Feature request: Provide a way for an AMP document to request installation of a Service Worker

[cramforce]

Something like

<amp-install-service-worker src="https://example.com/service-worker.js"></amp-install-service-worker>

should do it.

The Service Worker would only be installed when the document is loaded from the respective origin or the worker (right?) otherwise it is a noop.

CC @slightlyoff

[slightlyoff]

Yep, the SW root script needs to be fetched from the origin itself.

That said, you can pull things from other origins using importScripts() inside the SW (although they also need to be TLS origins). That might open up options for composition or the delivery of a default SW which you can customize w/ imports.

[jeffposnick]

In case it's useful: I'm thinking about a similar use case for a sample that I'm putting together. I wasn't sure about the cleanest way to register a top-level SW from within an article page that might be served a few levels down in the URL hierarchy. After some experimentation, I ended up with this approach that seems to work:

// Don't bother creating the <iframe> if we're already controlled by a service worker.
if ('serviceWorker' in navigator && !navigator.serviceWorker.controller) {
  var iFrame = document.createElement('iframe');
  iFrame.src = '/register-service-worker.html';
  iFrame.style.display = 'none';
  document.body.appendChild(iFrame);
}

Within /register-service-worker.html you'd make the actual navigator.serviceWorker.register('service-worker.js') call. Since the scope is top-level, the resulting service worker ends up controlling all pages on the site.

[cramforce]

@slightlyoff @jeffposnick So https://foo.com/bar/ cannot install https://foo.com/serviceworker.js?

In that case the iframe is fine.

I did not want to go towards installing service workers for the "home origin" when servings AMPs from a proxy domain although that would be an interesting future addition.

[jeffposnick]

Right, by default, https://foo.com/bar/ can't register a service worker that has an effective scope of /. The maximum effective scope (which is also the default scope) for a service worker registered at https://foo.com/bar/ is /bar/.

w3c/ServiceWorker#468 (comment) has some background, along with a reference to a Service-Worker-Allowed response header that could be used to relax that restriction. The header made it into the spec, but I don't know if it actually has any effect in Chrome or Firefox at the moment.

[jeffposnick]

As it turns out, I'm giving out bad advice, and was implementing things incorrectly in my own project.

https://foo.com/bar/ can install https://foo.com/serviceworker.js without requiring the <iframe> hack I suggested. I thought that the scope restriction was relative to the registering page, but it's actually relative to the service worker script.

[cramforce]

Ah, that is what I though. Great. Makes this much simpler :)

Can https://bar.com/ install https://foo.com/serviceworker.js ? The modern equivalent of cookie dropping :)