Open jakearchibald opened 5 years ago
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?
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.
@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.
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).
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?
I believe this is discussing this explainer: https://github.com/WICG/sw-launch/blob/main/sw_launch_event.md
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, viarespondWith
.As it stands, what's the deadline for calling
preventDefault
? Is it when all promises passed towaitUntil
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?
Is this a "URL handler" or a content-type handler?
I'm guessing the site would need permission to show notifications?
I agree with this as a goal, but it seems to clash with:
Since it's async, it isn't really analogous.
If the developer calls
openWindow
ornavigate
on a client within thelaunch
event, could that in turn trigger a launch event?Where? It isn't clear how this would work in a multi-window system.