Should we handle the launch event in the ServiceWorker or an Open Window

[comp615]

Moving some discussion over from here: https://github.com/WICG/file-handling/issues/3. There's a lot of good content in there, and it seems worthwhile that spec should use whatever is decided here.

An Idea One proposal was a compromise of the two proposals in the explainer:

• activate event is triggered for a specific origin
• if that origin has an associated service worker, see if it has an activate handler and pass it the event if so.
• if the service worker does not have a handler, or default is not prevented (explicitly or by doing client, select the best candidate window and trigger the activate event on it (this can remove the boilerplate of having to get it to a window)
• if the window does not have a handler (or does not preventDefault), refresh to the default URL or post the data or whatever
• if no window is open, open a new one and repeat the previous two events (note we get into a bad place with lazy loading here on Twitter, may need a helper tool which many would say is already the SW, but it's what we do with Windows)

Benefits:

• Works by default
• Most handling logic for use cases will reside in the window anyways (navigation for SPAs, loading info into an editor / preview)
• Dev can opt-in to window choosing by adding SW handling
• SW handling can provide advance functionality (e.g. background uploads)

Downsides:

• More surface areas touched
• Potentially harder to describe
• Still has slow service worker boot potential (not sure if you can tell if the event handler is registered before trying to boot it)

Comparison to Windows UWP Windows uses activated events on the window to handle this. There's a few gotchas with this that we had to address. The first is we have a lazy-loaded single page app. This means even though we wanted to lazily load Windows functionality (as others might want to do for say an image editor interface), the handler / listener itself needed to be in the main bundle, and then hang onto the event until the other code was loaded.

In addition, much for the same reason, we needed a way to show something while the event was handled. By default, this is the home launch path, which caused some jank or extra code. An ideal implementation for us, would start on the appropriate path (e.g. /compose) and then trigger the activate event for us to properly parse into the page.

I'm interested in thinking about the use cases where the SW would want to do something with the launch event. Or where other drawbacks to this approach might exist from a browser design perspective.

Hope that helps!

[raymeskhoury]

Thanks @comp615.

One thought - could the per-window behavior just be polyfilled? I think that maybe it could (by capturing the event in the SW, postMessaging it to the page and firing it). If that's the case, then I think I'm in favor of keeping the API design simpler by only firing the event on the service worker. WDYT?

[fallaciousreasoning]

Currently @raymeskhoury and I are thinking about a solution like this:

1. Specify an open_url in manifest.json (this would be /compose in your example).
2. Check if there is a launch event handler. 2.1 Yes: Let service worker redirect launch (postMessage the files to an existing window, open a new window, display a notification or act as if there was no launch event). 2.2 No: Navigate to open_url in a new window. Add an event listener to the window's load event, which the browser will pass the file handles to.

Note: We're not set on using load, we could use DOMContentLoaded or a completely new event (e.g. launch). It just seems like a good place to start.

I think this resolves your problem around opening /compose directly, I'm less sure about the lazy loading but I imagine you would include the launch handling code on the /compose page directly instead of lazy loading it. What do you think @comp615?

[comp615]

Circling back here after a while. We just implemented share target v2, and I wasn't thrilled with the implementation around how that works, so I'm hoping the launch event can help streamline things for developers.

I like 2.2, the major issue I ran into with the current system is that it's really tedious for a single-page app to deal with launch params. It requires:

1. Catch the specific request in the SW (requires SW coordination with manifest)
2. Redirect the automatically launched window to a special location so that it will notify the SW when it's launched.
3. Collect all the params, and the launched window ID. Add a Broadcast listener for when the launched window is "ready"
4. postMessage back the collected params.

I do think 2.2 let's developers get around this by just listening for the event and handling params once the page is loaded. I'm not 100% sure since I work by prototyping things, but it seems reasonable. My main concern is that we have examples and think about both client-side apps and server side apps so as to not hurt either architecture.

Relatedly, it's important that in implementation, the chosen window (however this happens) does not get auto-refreshed. So it'd be good to clarify if that requires handling by the SW, or if 2.2 can be used to auto-select a window without reloading it.

[alancutter]

We will let the site decide declaratively. For new launches will enqueue a LaunchParams in the targeted window, later we plan to allow sites to route it via the service worker to pick which window to use.