Considerations around `launch` or `activate` events

[comp615]

Copying over a little more context from other discussions, I wanted to discuss https://github.com/WICG/sw-launch/blob/master/explainer.md#whether-launch-events-should-only-be-triggered-by-navigations

There are many interesting concerns in that section.

Naming The launch event implies that the event is the first time the window is opened. Calling it activate may make it more clear to developers that it can be repeatedly called.

Consider one of the main pain points right now. If I have Twitter open, and I share from another app. It (rightly) focuses the main app window, but then reloads the page. In this case, I would expect that main window event handler to grab the params and process then appropriately

urls vs handlers This leads into the question of urls vs handlers. I do like the idea that everything goes to a link. It's possible that for almost any event, the app isn't loaded yet, and it may need direction of where to go (a start_url if you will). As mentioned above, this can be useful even with a full handler. Perhaps events can still require a canonical url, while also handling in in JS for SPAs.

Comparison to Windows Windows worked where launch events were interchangeable so you had to sort of scope the event down using event.type to see what it held. There may be a better design, but not sure. In some cases (like a notification click) the event fires on the main window. In others (e.g. share) it creates a new small sub-window.

It might be worth picturing creative ways the OSes or other places might use this event. For instance, could it ever start a widget on Android? Or maybe windows would want to do something similar?

[fallaciousreasoning]

Activate does seem a bit more intuitive to me. However, I think there's already an activate event in service workers (it's called when a new service worker registration is made active).

I think 'navigate' was also considered but there were worries it would get confused with fetch (this was before my time, so take it with a grain of salt).

Thanks for all your contributions on this it's really appreciated (and it's awesome to have feedback from someone who will actually be using the API!).

[raymeskhoury]

Naming

Your suggestion makes sense but I also agree with @fallaciousreasoning above that the terminology might be overloaded in th eweb platform.

urls vs handlers

I think I'm also starting to like the idea of everything being a navigation.

As mentioned above, this can be useful even with a full handler. Perhaps events can still require a canonical url, while also handling in in JS for SPAs.

I'm not sure how framing the launch in terms of a navigation to a URL is useful even if you have a full launch event handler specified on your service worker? Could you elaborate more?

In some cases (like a notification click) the event fires on the main window. In others (e.g. share) it creates a new small sub-window.

Just so I make sure I understand correctly, under the windows model, would it always create a new window of some kind (if one didn't already exist) before firing the event?

It might be worth picturing creative ways the OSes or other places might use this event. For instance, could it ever start a widget on Android? Or maybe windows would want to do something similar?

Do you mean home screen widgets? That could be a possibility. We've definitely talked about triggering things like notifications from the launch event handler (see the examples in the explainer :)

[fallaciousreasoning]

With regards to urls versus handlers, we've been talking about this quite a bit. I'm pretty close to convinced that urls are the way to go (in addition to handlers for SPAs)

My only real concern is that we'd be introducing a lot of API surface and it could be difficult to reason about flow.

[fallaciousreasoning]

I'm not sure how framing the launch in terms of a navigation to a URL is useful even if you have a full launch event handler specified on your service worker? Could you elaborate more?

This would mean we could do some jiggery pokery for initial app launches. We wouldn't have to spin up a service worker because we know it has to be opened in a new window, so we wouldn't have to fire a launch event (assuming launch events ONLY decide where to handle the event).

[raymeskhoury]

We wouldn't have to spin up a service worker because we know it has to be opened in a new window, so we wouldn't have to fire a launch event

Ah, I see. I guess it would mean there is less control? e.g. the site couldn't just show a notification?

[fallaciousreasoning]

Ah good point, I'd forgotten about notifications.

[fallaciousreasoning]

Having talked to the native-file-system folks, it sounds like the way file handles will be serialized won't be suitable for storing in the url (and there are concerns about lifetimes of the file handles). They suggested having an object, perhaps navigator.launchParams which contains file handles. This launchParams object could also be passed into the launch event handler in the ServiceWorker.

@dominickng do you have any thoughts?

[dominickng]

An object seems reasonable to me. How does that affect the everything-is-a-navigation semantics?

[fallaciousreasoning]

It doesn't really. My main concern is that this launchParams object is kind of weird. I don't know of any other API that does something like this on other platforms (or on the web). Apart from that it seem reasonable.

Will we have to worry about breaking websites if we add a new object (e.g. could it conflict with something websites are already doing?).?

[fallaciousreasoning]

@raymeskhoury and I were talking this morning and we were thinking of adding it to one of the existing Events that tell the page when it's been loaded (e.g. load, DOMContentLoaded) instead of adding it to the global object. This gives us slightly saner lifecycle semantics (imagine if we postMessaged new launchParams to an existing window: The window's launchParams might not necessarily reflect what was postMessaged to it most recently).

I envision it working something like this:

window.addEventListener('load', event => {
    if (!event.launchParams || !event.launchParams.files) return;

    const fileHandles = event.launchParams.files;
    // TODO: Stuff with files...
}

I'd feel a lot more comfortable about this kind of approach. If we're reluctant to add it to one of these existing events we could event create a new one.

[dominickng]

Hmmm, that is actually quite nice, and mirrors what we do with beforeinstallprompt event. :)

[alancutter]

To close off this issue after 3 years...

Naming: The LaunchQueue interface implies there can be more than one launch. URLs: The LaunchParams interface has targetURL which defaults to start_url so there is always a URL for every launch. Windows: The client_mode parameter could be extended with things like new-widget or new-popup if need be though it seems unlikely that there would be strong demand for that behaviour.