Re: [manifest] Integration with service workers (#161)

## Install from the app

marcoscaceres wrote:
> As far as I can see, it means throwing away all the registration machinery that a developer gets with navigator.serviceWorker.register(). Would they, and us, really want to do that?

What do you think would be thrown away? Would this not just be a declarative equivalent of navigator.serviceWorker.register() which in fact calls that method under the hood?

> I don't understand why developers wouldn't just do the following prior to installation (or what advantage the manifest brings over just doing the following prior to installation of the web app) [register service worker on page load].

That's a fair point. I would say:
* We should consider the case where service worker registrations don't survive the install process. I agree this could be considered a bug, but it may end up being quite common. Would Firefox on Android, Chrome on iOS or even Chrome on Android be able to guarantee this? Right now even Firefox OS uses a completely separate "data jar" for an installed app than for browser tabs for privacy reasons.
* I think you could argue that an app developer choosing to only register a Service Worker if the user explicitly "installs" the app to their device could be considered a valid design choice. I suspect proponents of Service Workers would argue that everything should use Service Workers by default, but perhaps that choice could be left to the developer?

An example use case might be the Pinned Apps design concept where all web apps can be used as a one-off in the browser without being installed, but the user may explicitly pin an app they want to persist to their device and use separately from the browser https://wiki.mozilla.org/FirefoxOS/Pinned_Apps

## Install from an app store

jakearchibald wrote:
> enabling an install flow for app-store like things. Personally I'd love to see search engines provide this functionality. Given Mozilla has a web app store, is it something they're keen on?

I don't think the current Web Manifest spec serves this use case very well today as there's no API for a web page to install an app from another origin. The user agent has to detect the manifest and give the user the option to "add to home" or similar when they are already using the app in the browser. It may be that due to a quirk of the way Web Manifest is implemented in Gecko it's actually possible to use the mozApps installation API with a Web Manifest, but that would be a proprietary API and is likely to go away.

This might be a use case which gets addressed in future, but right now I don't think it necessarily makes a good argument for this feature.

## Install from a product page

Something this could potentially be useful for is if the user installs the app from the app's product page on the same origin as the app. For example, https://evernote.com/ might not register the Service Worker, but https://evernote.com/Home.action would. Installing the app from https://evernote.com/ could therefore register the Service Worker declared in the manifest.

## Uninstall

Another use case I just thought of is that when a user uninstalls the app from their operating system, the service_worker property could perhaps also be used to unregister the Service Worker.

## Installation script

Some of the use cases described above may be a little weak, but I do think that the ability for a developer to use a Service Worker as an installation script for their app in general could be very powerful. There are all kinds of things a developer might want to trigger when the user installs their app other than populating a cache - from populating default data in a database or calling home to measure install metrics, to simply thanking the user.

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/issues/161#issuecomment-70080262