Add LaunchHandler API #2395
Add LaunchHandler API #2395
Conversation
github-actions
bot
added
the
feature definition
|
Need to figure out why there's no manifest key... |
| description: The Launch Handler API allows developers to control how a progressive web app (PWA) is launched, for example if it uses an existing window or creates a new one, and how the app's target launch URL is handled. | ||
| spec: https://wicg.github.io/web-app-launch/ | ||
| group: progressive-web-app | ||
| compat_features: |
There was a problem hiding this comment.
I think we need to add html.manifest.launch_handler and html.manifest.launch_handler.client_mode.
| - api.LaunchParams | ||
| - api.LaunchParams.targetURL | ||
| - api.LaunchQueue | ||
| - api.LaunchQueue.setConsumer | ||
| - api.Window.launchQueue |
There was a problem hiding this comment.
I think there might be two separate features here.
Developers can use the launch_handler manifest member to decide how the PWA launches (new or existing window). That part is captured by the 2 BCD keys I suggested before.
In addition, they can write code to handle whatever thing the PWA was opened with. A PWA can be opened as a result of multiple things:
- In the file explorer/Finder, the user opens an file that's associated with the PWA.
- From another app, the user shares a file/url/text/image by using the OS built-in share dialog, and chooses the PWA as a target.
- In another app, the user activates A URL that's associated with this app.
All of the above have the ability to trigger the launch of the PWA, and the PWA needs to be able to handle the thing that was used to open it (file, shared content, link). This is done with launchQueue and launchParams.
As a developer, I see the two above scenarios as separate. I can write code to handle shared or associated content when my app launches. And I can decide if a new instance of my app is spawned when the PWA is launched.
There was a problem hiding this comment.
How about naming the manifest-based feature app-launch (like now), and the launchQueue/Params feature app-launch-consumer?
@tomayac: can you take a look and let us know if you think developers think of the 2 things I described in my previous comment as, indeed, separate?
There was a problem hiding this comment.
I think they need to be thought of holistically, especially in the focus-existing case.
Note that the launch queue stuff is also shared by file_handlers:
api.LaunchParamsapi.LaunchParams.files(new, above it wastargetURL)api.LaunchQueueapi.LaunchQueue.setConsumerapi.Window.launchQueue
There was a problem hiding this comment.
Thanks Thomas.
Regarding file handing:
We already have a file handler feature on the repo and we decided to link it to html.manifest.file_handlers and api.LaunchParams.files. That's because the parent BCD key api.LaunchParams can be used for more things than just file handling. And because api.LaunchQueue* can also be used for more things.
There was a problem hiding this comment.
@tomayac is it correct that window.launchQueue can be used as a result of the following user scenarios?
- In the file explorer/Fider, the user opens an file that's associated with the PWA.
- From another app, the user shares a file/url/text/image by using the OS built-in share dialog, and chooses the PWA as a target.
- In another app, the user activates A URL that's associated with this app.
If so, I would still be tempted to create a feature just for api.LaunchParams, api.LaunchQueue, api.LaunchQueue.setConsumer, api.Window.launchQueue called something like app-consume-launch, and then another feature for html.manifest.launch_handler and html.manifest.launch_handler.client_mode called something like app-launch.
If not, then let's group all these keys together in a single feature called app-launch.
There was a problem hiding this comment.
Coincidentally, I had to dig this up today as well. Here are the launch triggers: https://github.com/WICG/web-app-launch/blob/main/launch_handler.md#background.
No description provided.