How should launchParams (fileHandles) get to the client window?

[fallaciousreasoning]

A number of different approaches have been proposed:

• A new launch event on the client window
• Encoding the file handles in the query string of the opened window (e.g. /open-file?file=file-handle://{GUIDish})
• Attaching launchParams to an existing event (i.e. load or DOMContentLoaded)
• Exposing a static launchParams object on window
• Exposing a promise getLaunchParams on window that resolves to a launchParams object.

Our preferred approach was to encode the file handles in the url, as back/forward semantics come for free. However, lifetime semantics are hard, and file handles are not trivial to serialize in this form. We're hesitantly tending toward attaching launchParams to the load event, though an initial prototype might expose a promise on the window, for ease of implementation.

@raymeskhoury anything to add?

[inexorabletash]

@mkruisselbrink may want to weigh in.

[mkruisselbrink]

I know you already said that the encoding in the query string is no longer your preferred approach, but just to reiterate why I think that approach wouldn't be the best either:

I definitely would not do the query string encoding thing. As discussed, really the only way to make that work is to have a special method to which you would then have to pass the special string, which would then return the actual handle. But since this special method is then still going to verify that this is actually a valid special string that was passed to the document (i.e. you can only call this method with the string that the document was launched with), why would you even need to pass in the string to begin with.

Also I don't quite understand what benefits this approach would have to begin with, you say:

back/forward semantics come for free.

But I'm not even sure what back/forward semantics you would be looking for. Should back/forward navigations actually include files like this? I'm not convinced it should, or at least shouldn't without a prompt. In that case embedding it in the URL seems to just be more confusing. Also you'd still not be getting anything for free, since whatever method can actually deal with these special encoded strings would still need to be defined, and would need to define what back/forward semantics you want.

With that out of the way, all the other options seem fairly reasonable to me. Can't really think of any reasons why either of those options wouldn't work. Some thoughts:

• adding it to an existing event (like load) has the disadvantage that the document wouldn't be able to access the launch params until that event actually fires. Given that afaik the load event doesn't fire until the entire document is loaded, this seems kind of unfortunate. Not sure how reasonable it is to want to know what you were launched with before all (non-deferred) images, stylesheets, iframes, etc are loaded.

• a related problem with a new launch event is that it isn't clear when you'd fire the event. You could wait to fire it until after the load event, but that has the same potential downsides again. You could fire it earlier as soon as you detect that a event listener is installed, but triggering anything on installing an event handler is not the best API design either.

• Re "Exposing a static launchParams object on window" I assumed you don't mean static as in WebIDL 'static' (i.e. Window.launchParams), but instead you just mean a regular attribute on the window object/Window interface? (i.e. window.launchParams or self.launchParams).
  FWIW this is the approach WebIntents took, with its window.intent.data etc attributes.

[raymeskhoury]

But I'm not even sure what back/forward semantics you would be looking for. Should back/forward navigations actually include files like this? I'm not convinced it should, or at least shouldn't without a prompt.

I had the same feeling.

adding it to an existing event (like load) has the disadvantage that the document wouldn't be able to access the launch params until that event actually fires.

Good thought.

[fallaciousreasoning]

Currently, we're considering updating the Launch Events proposal to better support some of the use cases here, and this will probably be handled there.

This is my current thinking:

Attach a launchParams object to the window. It will be available immediately with the parameters the PWA was launched with. It will also expose an event onlaunch (addEventHandler('launch', (newLaunchParams) => ...)) where the window can decide if it wants to handle a launch. If it does, then the launch params object will be updated.

[fallaciousreasoning]

Closing, as I think this problem is a concern for Launch Events, not file handling.