-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add explainer for launch_handler member #14
Changes from 9 commits
ae3c661
af2d564
5c482d7
52652da
1dcd45c
86a2c34
c943305
bc073ba
9dd9ab9
8591a72
9f2fac6
be471cc
95a2001
68d829c
9dbb193
96d6615
ad3d230
857d654
1d58fd2
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,141 @@ | ||
# Web App Launch Handling | ||
|
||
## Overview | ||
|
||
This document describes a new `launch_handler` manifest member that enables | ||
web apps to customise their launch behaviour across all types of app launch | ||
triggers. | ||
|
||
|
||
## Use Cases | ||
|
||
- Web apps that are designed to be used in a single window e.g. a music app. | ||
|
||
- Web app that capture and handle share target events and user navigations | ||
in existing windows without invoking a navigation and losing existing state. | ||
E.g. sharing an image to a chat web app could open a contact picker overlayed | ||
on top of existing chat content. | ||
|
||
|
||
## Background | ||
|
||
There are several ways for a web app window to be opened: | ||
- [File handling](https://github.com/WICG/file-handling/blob/main/explainer.md) | ||
- [In scope link capturing](https://github.com/WICG/sw-launch/blob/master/declarative_link_capturing.md) | ||
- [Note taking](https://wicg.github.io/manifest-incubations/index.html#note_taking-member) | ||
- Platform specific app launch surface | ||
- [Protocol handling](https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/URLProtocolHandler/explainer.md) | ||
- [Share target](https://w3c.github.io/web-share-target/) | ||
- [Shortcuts](https://www.w3.org/TR/appmanifest/#dfn-shortcuts) | ||
|
||
Web apps launched via these triggers will open in a new or existing app window | ||
depending on the user agent platform. There is currently no mechanism for the | ||
web app to configure this behaviour. | ||
|
||
|
||
## Proposal | ||
|
||
- Add a `launch_handler` member to the web app manifest specifying the default | ||
client selection and navigation behaviour for web app launches. | ||
The shape of this member is as follows: | ||
``` | ||
"launch_handler": { | ||
"route_to_client": null | "new" | "existing", | ||
"navigate_client": null | true | false | ||
alancutter marked this conversation as resolved.
Show resolved
Hide resolved
|
||
} | ||
``` | ||
|
||
If unspecified then `launch_handler` defaults to | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't think leaving it up to the user agent is good. Usually, this is done for three reasons:
None applies here. This does concern the site developer because it changes what events they need to be ready for. For example, The default behaviour should be prescribed as However that's not really right either. It seems that the intended implementation here is that HOWEVER, really this last point applies only to link capturing, not other forms of launching like the home screen icon, shortcuts, share targets, etc, which would always open a window. So in fact, this is a third orthogonal choice. So there actually should be a third value here, called ... tada ... You could also put So we're left with: "launch_handler": {
"route_to": "new" | "existing", // default = "new"
"navigate_client": true | false // default = "true"
},
"capture_links": true | false // default = false The default value aligns exactly with what we have today, in a pre-launch-handler world. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Good point re
Re Re link capturing: I don't think we should block users from enabling link capturing for web apps nor should we enable link capturing without the user's opt in. This makes link capturing behaviour a user decision configured in the user agent rather than the site manifest. |
||
`{"route_to_client": null, "navigate_client": null}` whereby the behaviour | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. wouldn't that not be undefined in JS sense then? It is JSON after all There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Do you mean undefined instead of null or undefined instead of There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. well, if launch_handler is undefined then so are launch_handler.route_to_client and launch_handler.navigate_client I don't see any reason to introduce null here. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It makes more sense with this part of the proposal:
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It could be like (pseudocode):
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Just a point of clarification: I believe @kenchris is merely saying that these should be |
||
is up to the user agent. | ||
|
||
Both `route_to_client` and `navigate_client` also accept a list of values, the | ||
first valid value will be used. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Please explain why (this is for forwards-compatibility). There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Done. |
||
|
||
Example manifest that choses to receive all app launches as events in existing | ||
web app windows: | ||
```json | ||
{ | ||
"name": "Example app", | ||
"start_url": "/index.html", | ||
"launch_handler": { | ||
"route_to_client": "existing", | ||
"navigate_client": false | ||
} | ||
} | ||
``` | ||
|
||
- Enqueue a [`LaunchParams`]( | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is hard to understand if someone hasn't read/used file handling (it implies that I think you should add a whole section to this explainer for There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Brought in |
||
https://github.com/WICG/file-handling/blob/main/explainer.md#launch) | ||
object in the DOM Window's `launchQueue` of the chosen client **for every web | ||
app launch**. | ||
|
||
- Add a `url` field to `LaunchParams` and set it to the URL being launched if | ||
the chosen launch client is not navigated as part of the launch. | ||
|
||
Other web app APIs that involve launching may extend the `LaunchParams` with | ||
more data specific to the method of launching e.g. a [share target]( | ||
https://w3c.github.io/web-share-target/) payload. | ||
|
||
|
||
## Future extensions to this proposal | ||
|
||
- Add a service worker `"launch"` event that intercepts every web app launch. | ||
The service worker can choose to override the value of `route_to_client`, | ||
`navigate_client` and `LaunchParams`. | ||
|
||
**Use case:** Opening a productivity web app via a | ||
[file handler](https://github.com/WICG/file-handling/blob/main/explainer.md) | ||
causes an existing window that already had the file open to come into focus | ||
instead of launching a duplicate window. | ||
|
||
- Add a `new_client_url` member to the web app manifest. All new clients that | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. As discussed, this won't be used at all if we change There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Updated. |
||
don't navigate to the launch URL will open `new_client_url` instead. | ||
|
||
If `new_client_url` is the default value `null` then behave as if it is set to | ||
the value of `start_url`. | ||
|
||
**Use case:** Web apps that have heavy `start_url` pages and want to avoid | ||
loading unnecessary resources. | ||
|
||
- Add the `launch_handler` field to other launch methods to allow sites to | ||
customise the launch behaviour for specfic launch methods. E.g.: | ||
```json | ||
{ | ||
"name": "Example app", | ||
"description": "This app will navigate existing clients unless it was launched via the share target API.", | ||
"launch_handler": { | ||
"route_to_client": "existing", | ||
"navigate_client": true | ||
}, | ||
"share_target": { | ||
"action": "share.html", | ||
"params": { | ||
"title": "name", | ||
"text": "description", | ||
"url": "link" | ||
}, | ||
"launch_handler": { | ||
"navigate_client": false | ||
} | ||
} | ||
} | ||
``` | ||
|
||
|
||
## Related proposals | ||
|
||
|
||
### [Declarative Link Capturing](https://github.com/WICG/sw-launch/blob/main/declarative_link_capturing.md) | ||
|
||
`launch_handler` generalises the concept of `capture_links` into two core | ||
primitive actions (launch client selection and navigation) and more explicitly | ||
decouples them from the specific "link capturing" launch trigger. | ||
|
||
|
||
### [File Handling](https://github.com/WICG/file-handling/blob/main/explainer.md) | ||
|
||
This proposal takes the `LaunchQueue` and `LaunchParams` ideas from the File | ||
Handling proposal and extends them slightly. Instead of enqueuing `LaunchParams` | ||
for specific types of launches they will be enqueued for every type of web app | ||
launch. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As I said privately, I think it would be good to incorporate (mostly copy+pasting) the use cases and other background from the DLC explainer, since this is largely solving the same use case.
Also you should explain up front that the DLC explainer (which a lot of people are probably familiar with by now) is an older version of this. Not something that will co-exist.
All of these sections can appear verbatim or with minor changes:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated overview to explain on declarative approach.
launch_handler is a subset of DLC, they may co-exist if the overlap is removed from DLC (though sw-launch would probably not the right place for it anymore).
This part is out of scope for launch_handler:
Mentioned DLC in the background section.
Security & privacy isn't the same without link capturing in scope, that section still looks DLC specific.
Added missing related proposal sections.