Closed comp615 closed 1 year ago
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?
Currently @raymeskhoury and I are thinking about a solution like this:
open_url
in manifest.json
(this would be /compose
in your example). 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 useDOMContentLoaded
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?
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:
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.
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.
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:
Benefits:
Downsides:
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!