Old service worker launch event explainer discussion

[jakearchibald]

Sorry for throwing this all into one issue. Some of it is just nits:

---

I think this is the first API that allows event.preventDefault async. I could be mistaken, but even if I'm not, I don't know if it's a bad thing. In the fetch event, preventing the default is synchronous, via respondWith.

As it stands, what's the deadline for calling preventDefault? Is it when all promises passed to waitUntil settle?

---

What happens if the POST data is read from the request, but the default isn't prevented?

---

It doesn't seem like there's a way to tell between a browser tab and a standalone added-from-homescreen window. Should there be one?

---

URL Request Handlers: A user navigates to a PDF and it is opened using a PDF viewer web app.

Is this a "URL handler" or a content-type handler?

---

show a notification

I'm guessing the site would need permission to show notifications?

---

they can say "Open in new tab" and the app will not be allowed to prevent the page from opening

I agree with this as a goal, but it seems to clash with:

Banking websites as well as messaging apps can often fail if users try to use them from multiple tabs. This API could be used to bounce the user back into an existing tab if they already have one open.

---

preventDefault is analogous to FetchEvent's respondWith method.

Since it's async, it isn't really analogous.

---

If the developer calls openWindow or navigate on a client within the launch event, could that in turn trigger a launch event?

---

Show a splash screen indicating the app is launching

Where? It isn't clear how this would work in a multi-window system.

[fallaciousreasoning]

Sorry for throwing this all into one issue. Some of it is just nits:

No worries, the feedback is much appreciated!

---

I think this is the first API that allows event.preventDefault async

I think you're probably right. I had a chat with @raymeskhoury and we decided we probably don't need this at all anyway, as we're requiring that the launch event MUST do something in order for the browser to consider the launch handled.

I'm removing it from the explainer in #16

(the deadline would have been promises in waitUntil settling, or some user-agent specified timeout).

---

What happens if the POST data is read from the request, but the default isn't prevented?

I'm unsure. I'm adding a note in the explainer. What does fetch do if you read some of the post data and don't respond?

It'd be kind of nice if this could run in parallel to the fetch handler, but that might be kind of difficult...

Maybe we could restrict this to not be able to read the body of the request? As we're expecting to apply a pretty aggressive timeout, it doesn't seem too unreasonable.

---

It doesn't seem like there's a way to tell between a browser tab and a standalone added-from-homescreen window. Should there be one?

Based on https://chromium.googlesource.com/chromium/src/+/master/docs/security/permissions-for-powerful-web-platform-features.md, I tend to think not, but I'm open to being convinced. I think there has been some discussion of an API for detecting whether your app is installed, and I think we can let this be resolved in the same way as that.

---

Is this a "URL handler" or a content-type handler?

I'm unsure, but I think it works either way as an example of the kind of useful APIs we could build on top of this :)

---

I agree with this as a goal, but it seems to clash with:

Good point, I'll remove it from the example.

---

Since it's async, it isn't really analogous.

Removing reference to preventDefault

---

If the developer calls openWindow or navigate on a client within the launch event, could that in turn trigger a launch event?

I tend to think not. At least, not for the same app. We're intending to trigger launch events only for out-of-app to inside-app navigations, though I guess there are some weird scenarios we need to consider here (such as when the PWA's scope is more restricted than that of the ServiceWorker).

However, we're discussing the out-to-in requirement at the moment, so this could change.

---

Where? It isn't clear how this would work in a multi-window system.

I think the splash screen would be something like the splash screen we show for Android PWAs, though this seems like it would only work if the app was going to open a new window. @raymeskhoury do you have any more background?

[raymeskhoury]

What happens if the POST data is read from the request, but the default isn't prevented?

What happens in the case of fetch?

It doesn't seem like there's a way to tell between a browser tab and a standalone added-from-homescreen window. Should there be one?

Do you mean how to tell the difference inside of a window? I think you can query the display mode of the window: https://developer.mozilla.org/en-US/docs/Web/CSS/@media/display-mode

I'm unsure, but I think it works either way as an example of the kind of useful APIs we could build on top of this :)

content-type handler may be a better description :)

If the developer calls openWindow or navigate on a client within the launch event, could that in turn trigger a launch event?

It's a good point. I think we need to be careful of that. Requiring a user gesture to trigger a launch event should mitigate a lot of these concerns.

Where? It isn't clear how this would work in a multi-window system.

I was thinking that just as many apps on Windows show a splash screen, you could do something similar. You could do that even if the app was already open.

[jakearchibald]

@fallaciousreasoning

It doesn't seem like there's a way to tell between a browser tab and a standalone added-from-homescreen window. Should there be one?

Based on https://chromium.googlesource.com/chromium/src/+/master/docs/security/permissions-for-powerful-web-platform-features.md, I tend to think not, but I'm open to being convinced.

You can already detect it via CSS media queries (and therefore via matchMedia in JS) https://developer.mozilla.org/en-US/docs/Web/CSS/@media/display-mode.

@raymeskhoury

What happens if the POST data is read from the request, but the default isn't prevented?

What happens in the case of fetch?

Good question. https://sw-post-read-test.glitch.me/ - seems to work fine. I guess the service worker gets a copy of the response. Tests should ensure this works here too.

It doesn't seem like there's a way to tell between a browser tab and a standalone added-from-homescreen window. Should there be one?

Do you mean how to tell the difference inside of a window?

Nah, I mean from the client object itself. Eg, for when you're deciding which client to focus.

Where? It isn't clear how this would work in a multi-window system.

I was thinking that just as many apps on Windows show a splash screen

The splash screen usually appears in a new window, which later displays the content. The launch event happens before the browser knows the target client.

[raymeskhoury]

Nah, I mean from the client object itself. Eg, for when you're deciding which client to focus.

Ahh good point. Right now you'd have to postMessage which isn't very fast or ergonomic. I've added this to the list of window API features we need to add.

The splash screen usually appears in a new window, which later displays the content. The launch event happens before the browser knows the target client.

That's true.

Perhaps all we really want to do is require the handler to do something (open window, focus window, show notification) within a small timeout and if it doesn't we resort to the default behavior. My concern with this is that it will be hard for developers to know that their handler isn't too slow and to debug when it is (on different machines).

[fallaciousreasoning]

Ahh good point. Right now you'd have to postMessage which isn't very fast or ergonomic. I've added this to the list of window API features we need to add.

Do you think we could get away with deferring this or adding it as a separate proposal? The window versus tab distinction doesn't seem like it would be super important when choosing which client to focus (though I could be wrong).

I don't think changing launch behavior based on the type of window the app is in is something we want to encourage (some apps work better as tabs, some as windows), so I feel pretty okay about the postMessage solution. It's possible if a developer really needs it, but not easy enough to do in other scenarios.

The splash screen usually appears in a new window

The explainer also mentions OS specific solutions: Bouncing the dock icon in OSX, coloring the icon on Windows ect. It may be that we can do something more tailored to specific OS's. The splash screen could still happen on Android (where I suspect but don't know that apps can't have multiple windows open).

My concern with this is that it will be hard for developers to know that their handler isn't too slow

In the development case, we could console.error a helpful warning that their launch handler was terminated for being too slow. I agree that this doesn't really help with other devices though.

Perhaps this information is something we could include in the launchParams that are passed to the page. We could include an error, if we have one.

const launchEvent = {
    cause: 'files',
    fileHandles: [...],
    error: new Error('Launch was terminated after {N} seconds (Launch events must respond faster than {M} seconds, in order to ensure a good user experience')
}

^ Something like that. Then, if developers care, they could report this, along with some additional information about the device they're running on.

Thinking about it, it would be generally useful to have information about how long the launch took attached to the event? @raymeskhoury do you think this could be worth adding?

[alancutter]

I believe this is discussing this explainer: https://github.com/WICG/sw-launch/blob/main/sw_launch_event.md