Web App Launch Handler

[alancutter]

Braw mornin' TAG!

I'm requesting a TAG review of Web App Launch Handler.

Web app launch handler is new launch_handler manifest member that enables web apps to customise their launch behaviour across all types of app launch triggers.
We found that almost all "launch" use cases could be covered by a select few fixed rules (for example, "choose an existing window in the same app, focus it, and navigate it to the launched URL"). This launch_handler proposal enables sites to specify a set of fixed rules without having to implement custom service worker launch event logic, which should satisfy most use cases, and simplify the implementation in browsers and sites.

This is a successor API to Declarative Link Capturing which has its own completed TAG review.

• Explainer: https://github.com/WICG/sw-launch/blob/main/launch_handler.md
• User research: Positive developer feedback from the DLC origin trial wanting to continue using the navigate-existing-client behaviour.
• Security and Privacy self-review: Web App Launch Handler: Security and Privacy self-review
• GitHub repo: https://github.com/WICG/sw-launch/issues
• Primary contacts (and their relationship to the specification):
  • Alan Cutter @alancutter, Google
  • Matt Giuca @mgiuca, Google
• Organization/project driving the design: Google
• External status/issue trackers for this feature:
  • https://www.chromestatus.com/guide/edit/5722383233056768
  • https://bugs.chromium.org/p/chromium/issues/detail?id=1231886

Further details:

• [ X ] I have reviewed the TAG's Web Platform Design Principles
• The group where the incubation/design work on this is being done (or is intended to be done in the future): WICG
• The group where standardization of this work is intended to be done ("unknown" if not known): Web Apps WICG
• Existing major pieces of multi-stakeholder review or discussion of this design: Declarative Link Capturing TAG review
• Major unresolved issues with or opposition to this design:
• This work is being funded by: Google

You should also know that...

launch_handler is a piece of the larger web app link handling puzzle:
PWA Link Capturing and URL Handling: The New Taxonomy

We'd prefer the TAG provide feedback as:

💬 leave review feedback as a comment in this issue and @-notify [github usernames]

[hober]

The explainer starts out with this line:

Authors: alancutter@, mgiuca@, dominickn@ Last updated: 2021-07-09

I don't know if you put the at signs at the wrong end of your GitHub usernames or what, but it looks pretty weird.

[kenchris]

It is a bit confusing that the repo's main readme [1] doesn't mention this explainer or what is the current proposal being pursued, as well as what is not being pursued any longer

[1] https://github.com/WICG/sw-launch/blob/main/README.md

[kenchris]

When a client is being navigated, will this mean that a new entry is added to the session history so that you can get back to earlier state? (like right click on titlebar and click 'back')

Maybe we could even get rid of "existing-client" given that a site can always add a consumer and manually navigate?

launchQueue.setConsumer(launchParams => location.href = launchParams.targetURL);

This is especially interesting because I believe we want to avoid developers using navigate-existing-client as often as possible as it can be quite annoying to lose all state in an existing window - Personally that happens a lot on Android and I would not encourage people doing so. For instance if I clicked on a spotify song, I would rather either have it open another window or (better yet) have spotify focus the existing window and ask me whether to play the new song or add it to the playlist (youtube does similar when clicking on videos while using a chrome cast), that to throw away all my current state.

[hober]

The explainer is written in a way that assumes the reader has a lot more context than is necessarily the case. I think it would be useful to rewrite the explainer taking into account our advice in the Explainer explainer.

[LeaVerou]

Hi @alancutter,

We looked at this today during our virtual f2f. @hober and @kenchris have already relayed some of our questions above.

Bigger picture, one of our concerns is that this facilitates user hostile behavior, where new content entirely replaces old content and the user loses their current state.

For example, consider the native Google Maps application. Clicking a maps link from anywhere else replaces your current state with no means to retrieve it or toggle between the two (e.g. to compare routes). Even in the music player example, does the user desire for their state to be entirely replaced, or merely for the previous song to be paused?

We understand that it is possible to maintain the previous state with custom coding, but we are concerned that the easiest, most straightforward thing to do is what most native apps do, which is to entirely replace user state. We'd love it the Web could do better.

What are your thoughts about how to address this?

[kenchris]

@LeaVerou @alancutter my suggestion would be to simple drop the "navigate existing client" support. If people really want to do it, it can still be accomplished as shown above (#683 (comment)), but this way it is going to be harder to accidentally do.

Maybe we will end up with something like

"route_to": "new-client" | "existing-client-retain" | "service-worker"

I like the -retain in the name (@alancutter 's suggestion in another issue) as it means it clearer that the developer needs to do additional work

[alancutter]

Created issue to address default navigate/retain comments: WICG/web-app-launch#47

[maxpassion]

Hi @alancutter , we had a discussion in this week's TAG meeting and have the following comments:

1. It would be good to rewrite the explainer, for example, adding more use cases from the end-user need perspective, you can refer the tips in: https://tag.w3.org/explainers/

2. This proposal may also related to MiniApp lifecycle, it is better to be aligned or reusable as much as possible. Probably @QingAn can also have a look on this together.

[QingAn]

2. This proposal may also related to MiniApp lifecycle, it is better to be aligned or reusable as much as possible. Probably @QingAn can also have a look on this together.

MiniApp lifecycle also covers the use case of Application Launch. I think it's worth considering whether existing efforts could be brought together in some way.

[alancutter]

Sorry about the radio silence, I was temporarily fighting fires on a different project but can now dedicate my time back on this one.

It is a bit confusing that the repo's main readme [1] doesn't mention this explainer or what is the current proposal being pursued, as well as what is not being pursued any longer

[1] https://github.com/WICG/sw-launch/blob/main/README.md

It was very out of date indeed, updated.

The explainer starts out with this line:

Authors: alancutter@, mgiuca@, dominickn@ Last updated: 2021-07-09

I don't know if you put the at signs at the wrong end of your GitHub usernames or what, but it looks pretty weird.

The explainer is written in a way that assumes the reader has a lot more context than is necessarily the case. I think it would be useful to rewrite the explainer taking into account our advice in the Explainer explainer.

Hi @alancutter , we had a discussion in this week's TAG meeting and have the following comments:

1. It would be good to rewrite the explainer, for example, adding more use cases from the end-user need perspective, you can refer the tips in: https://tag.w3.org/explainers/

Adding fix ups and extra use case paragraphs to the overview. WICG/web-app-launch#50

2. This proposal may also related to MiniApp lifecycle, it is better to be aligned or reusable as much as possible. Probably @QingAn can also have a look on this together.

Filed WICG/web-app-launch#52 to dig into this. It looks quite hairy, I'll need some assistance in understanding the differences between web apps and MiniApps when it comes to launching and window instances.

[alancutter]

@LeaVerou @alancutter my suggestion would be to simple drop the "navigate existing client" support. If people really want to do it, it can still be accomplished as shown above (#683 (comment)), but this way it is going to be harder to accidentally do.

Maybe we will end up with something like

"route_to": "new-client" | "existing-client-retain" | "service-worker"

I like the -retain in the name (@alancutter 's suggestion in another issue) as it means it clearer that the developer needs to do additional work

In progress: WICG/web-app-launch#53
This resolves WICG/web-app-launch#47 nicely as you suggested.

[LeaVerou]

Hi @alancutter,

Talking a bit more about this in our F2F, we are a little concerned that the current proposal does not take user choice into account enough. There are valid cases for always navigating to a new client, always navigating to an existing client, and many more where it's less clear-cut and different use cases may call for different things. Per the Ethical Principles, users should be able to render content as they want. Would it be appropriate to have a specific user-choice option?

[alancutter]

We're envisioning in the concrete implementation that this new client/existing client behaviour to be what happens on a basic navigation. The user will always be able to explicitly "open in new window" or "open in new tab" and not trigger any capturing behaviour. This kind of user override is important to provide, I'll add some text to strongly recommend having such capabilities in the user agent on individual user navigations.

[torgo]

Hi @alancutter - thanks for that response. We're happy to see this move ahead. 👍 We'd like to see work move forward with the miniapp lifecycle work and other relevant stakeholders to ensure the strands are connected (as noted above by @QingAn): #683 (comment)