Clarify ServiceWorkerRegistrationObject’s purpose

[aarongustafson]

It’s not entirely clear what the ServiceWorkerRegistrationObject does or what it intends to do. It would be good to extrapolate with the use case(s), etc. For instance, is this for store packaging? Any other reasons? It would be good to have some detail in the spec.

Related: What’s the implementation story on this?

[aarongustafson]

Talked to @marcoscaceres and this appears to be a request in terms of syncing apps that never really materialized. No one appears to implement this and there are other ways to get around it and initialize a Service Worker, so we should seriously consider removing it from the spec as unnecessarily complex. Any objections?

[kenchris]

This was requested by Microsoft so that apps being installed from the Microsoft Store could install the service worker and populate cache while being installed but without needing the user to access the site.

Basically today you would be able to install, then go offline and when opening the app it wont work.

I don't know whether this was ever implemented but it does make sense for Web Packaging as well.

[mgiuca]

@raymeskhoury @jakearchibald and I discussed this yesterday. I think it would be good for just establishing an invariant that if the manifest is installed, the service worker is guaranteed to be installed too, which is established declaratively by it being mentioned in the manifest.

The current mechanism for registering a SW isn't really tying it to the app at all, it just happens to be two technologies that work together. So if the SW is removed due to storage pressure, the app breaks, and there isn't really any mechanism saying "no wait, this SW is more important to me because it's tied to an app".

@jakearchibald also suggested that we could automatically apply persistent storage to origins that have apps installed. But I really like the idea of formally linking an app to its SW.

I don't think this was ever implemented in any browser, but I'm in favour of a renewed push to implement, rather than removing this. Since it hasn't been implemented, we could change it if necessary.

Also, based on what I wrote in w3c/badging#55:

Apparently, y'all discussed [multiple apps governed by a single SW] and decided that was a use case we want to discourage. I'm hesitant about this, since I don't think the Badge API is the right place to make a stand on this: if we really think that sites should not have multiple apps per SW (i.e., each app should have a SW at the same scope as the app scope), then we should officially (in the Manifest spec) state that this is expected, and not having a SW at the same scope as the manifest is deprecated, and future APIs may not support multiple apps per SW.

Maybe if we believe that, this is a good place to start: remove scope from ServiceWorkerRegistrationObject, and always use the manifest scope, so that we enforce the rule that a service worker formally linked to an app manifest has the same scope as that app.

[aarongustafson]

The current mechanism for registering a SW isn't really tying it to the app at all, it just happens to be two technologies that work together. So if the SW is removed due to storage pressure, the app breaks, and there isn't really any mechanism saying "no wait, this SW is more important to me because it's tied to an app".

That makes total sense.

I don't think this was ever implemented in any browser, but I'm in favour of a renewed push to implement, rather than removing this. Since it hasn't been implemented, we could change it if necessary.

I’m not averse to that as long as we document the purpose of the member (and how it should be considered by a UA) better within the spec.

Maybe if we believe that, this is a good place to start: remove scope from ServiceWorkerRegistrationObject, and always use the manifest scope, so that we enforce the rule that a service worker formally linked to an app manifest has the same scope as that app.

+1 to that.

On the shared SW issue, my opposition was more to having one app within another (e..g., one with a scope of / and another with a scope of /inner-app) wherein URL-based disambiguation from within the SW might make updating the corresponding app icon more difficult.

[christianliebel]

Maybe if we believe that, this is a good place to start: remove scope from ServiceWorkerRegistrationObject, and always use the manifest scope, so that we enforce the rule that a service worker formally linked to an app manifest has the same scope as that app.

This would mean that we can’t replicate all possible Service Worker configurations in the manifest, which might break the requirement:

Talked to @marcoscaceres and this appears to be a request in terms of syncing apps that never really materialized.

This was requested by Microsoft so that apps being installed from the Microsoft Store could install the service worker and populate cache while being installed but without needing the user to access the site.

Also, as there can be more than one service worker script under a manifest scope, shouldn’t serviceworker actually take a list of registrations? I’m thinking of large applications (e.g. https://example.com) where different teams implement their own service worker for their segment (e.g. https://example.com/profile/, https://example.com/inbox/, …).

[mgiuca]

@aarongustafson

On the shared SW issue, my opposition was more to having one app within another (e..g., one with a scope of / and another with a scope of /inner-app) wherein URL-based disambiguation from within the SW might make updating the corresponding app icon more difficult.

Yeah... I don't like that story either but it's very hard to avoid. A store listing can simply prevent you from listing two apps that are nested inside one another. But a browser can't know about the other manifest. We've talked (on Chrome) about simply preventing the user from installing either an app scoped inside another already-installed app, or scoped outside an already-installed app. But we can't error either of those apps without seeing the other manifest.

Basically, not something we explicitly want to support, but not a condition we can detect either.

@christianliebel

we can’t replicate all possible Service Worker configurations in the manifest, which might break the requirement

What requirement?

Also, as there can be more than one service worker script under a manifest scope, shouldn’t serviceworker actually take a list of registrations?

I similarly don't really think we should be supporting multiple SWs per app. Ideally, we would have a 1:1 mapping from apps to SWs.

The reason multiple SWs per app is bad, well there are two configurations:

1. Non-nested SWs that cover different parts of the app. This isn't really supported at all today, since there is an effective (non-standard) requirement that the entire app scope be covered by a SW. If multiple non-nested SWs cover parts of the app scope, that implies the root scope isn't covered by any SW. So let's avoid this case.
2. One major SW covering the whole app scope, and then other nested SWs covering smaller parts of the scope. This technically works, but it's problematic, since the app may behave differently depending on which SWs are registered and in what order. For example, if the outer SW is registered first, its fetch handler may prevent the pages on the inner SW from registering themselves, unless it is carefully written. Even if it's written carefully, the app may behave brokenly when offline if the outer SW is registered (which is a requirement of installation) but the inner SW is not (which would not be a requirement).

If large sites require this, we could consider it later, but the initial version of service_worker should be limited to one SW, IMO.

[christianliebel]

What requirement?

The ability to download/sync a PWA from the store and have it offline-capable right off the bat (without ever opening it).

[mgiuca]

Had a chat with @marcoscaceres . I think there's a general feeling of, yeah, it might have some nice properties like declaratively linking a SW to a manifest, being able to sync and pre-install apps without loading a document to register a SW, but there's a lot of implementation complexity in registering a service worker through this out-of-band channel.

Maybe we get back around to this in the future, but for now, since nobody has implemented it (and it's way out of date), let's just take it out of the spec.

[boyofgreen]

@mgiuca @aarongustafson . With EdgeHTML packages we had this idea of "precaching", in which an app that was downloaded form the store would silently load the initial page to prime the cache at install time. This was to avoid the initial page load experience. I know a few Microsoft "productivity" apps that used it, but it wasn't often used. We suggested the change to registration object so we could put that same type of experience in place with the more logical service worker cache calls.
I would say it is still a very nice idea (helpful any time a PWA is installed from a source other than a button on a page that is already loaded) but not a current priority. Step one is just getting the content from the manifest to use for an external install.
Also my two cents on the nested SW, I think it will be a needed feature for enterprise adoption. We need a way for Service Workers to play nice together when multiple teams are working on the same site, and site hierarchies doesn't follow team structure :)

[marcoscaceres]

Also my two cents on the nested SW, I think it will be a needed feature for enterprise adoption. We need a way for Service Workers to play nice together when multiple teams are working on the same site, and site hierarchies doesn't follow team structure :)

I think this applies generally to service workers.