Intent to Ship: Web app launch handler

340 views
Skip to first unread message

Alan Cutter

unread,
Oct 18, 2022, 2:42:51 AM10/18/22
to blink-dev, Penelope McLachlan, Matt Giuca

Contact emails

alanc...@chromium.org, mgi...@chromium.org

Explainer

https://github.com/WICG/sw-launch/blob/main/launch_handler.md

Specification

https://wicg.github.io/sw-launch

Summary

Add a "launch_handler" web app manifest member that enables web apps to customize their launch behavior across all types of app launch triggers. Example usage: { "name": "Example app", "start_url": "/index.html", "launch_handler": { "client_mode": "navigate-existing" } } This will cause all launches of the Example app to focus an existing app window and navigate it (if it exists) instead of always opening a new app window.



Blink component

Blink>AppManifest

Search tags

web app, pwa, link capturing, link handling, launch

TAG review

https://github.com/w3ctag/design-reviews/issues/683

TAG review status

Issues addressed

Link to origin trial feedback summary

https://docs.google.com/document/d/1t60YeQ-d-FSr9i91jvylW6sA7_R4jDnX1G4_PDfssYE/edit

Risks


Web developers: Strongly positive. Feedback from sites using this API has been strongly in favor of keeping the functionality.

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None. This feature only affects installed web apps which run in a regular browser environment rather than a WebView.



Debuggability

Adding the field to DevTools is in progress.


Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

No, desktop only.

Is this feature fully tested by web-platform-tests?

No, this requires browser_tests as it involves managing windows.
Have raised an issue with testdriver.js for web app specific support.

Flag name

chrome://flags/#enable-desktop-pwas-launch-handler
kWebAppEnableLaunchHandler

Requires code in //chrome?

True

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1231886

Launch bug

https://launch.corp.google.com/launch/4207744

Non-OSS dependencies

Does the feature depend on any code or APIs outside the Chromium open source repository and its open-source dependencies to function?

None.

Estimated milestones

OriginTrial desktop last110
OriginTrial desktop first98


Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).


Currently launch_handler interacts poorly with share_target and may drop in-transit user data. This will be fixed with follow up spec additions to LaunchParams: https://github.com/WICG/sw-launch/issues/62
For the initial launch launch_handler will be ignored for share_target launches.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5722383233056768

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/8tNe2jrJ78A
Intent to Experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/wNOClobsLrs
Request to Extend Experiment (rejected): https://groups.google.com/a/chromium.org/g/blink-dev/c/pKl0eEeN5U4

Yoav Weiss

unread,
Oct 19, 2022, 8:52:32 AM10/19/22
to Alan Cutter, blink-dev, Penelope McLachlan, Matt Giuca
Hey! Thanks for pushing this :)

I went over the spec and filed a few issues. None of them seems blocking (as in, they won't change the API shape), but they'd help us achieve an interoperable specification.

Would it be possible for y'all to go over the issues list, close the ones that are no longer relevant, and then label ones that may contain any future compat risk, if any? (That is, issues that may change the API shape once resolved)

Aside: should the repo be renamed to "web-app-launch" or something similar?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANJJ2Cm9TG4E2ovLYZQR23pDA7AE%2BuYNpk6du-dZV4p2vgfvPg%40mail.gmail.com.

Matt Giuca

unread,
Oct 19, 2022, 11:29:28 PM10/19/22
to Yoav Weiss, Alan Cutter, blink-dev, Penelope McLachlan
Hey Yoav,

On Wed, 19 Oct 2022 at 23:52, Yoav Weiss <yoav...@chromium.org> wrote:
Hey! Thanks for pushing this :)

On Tue, Oct 18, 2022 at 8:42 AM Alan Cutter <alanc...@chromium.org> wrote:

I went over the spec and filed a few issues. None of them seems blocking (as in, they won't change the API shape), but they'd help us achieve an interoperable specification.

Would it be possible for y'all to go over the issues list, close the ones that are no longer relevant, and then label ones that may contain any future compat risk, if any? (That is, issues that may change the API shape once resolved)

Aside: should the repo be renamed to "web-app-launch" or something similar?

It probably should!

Historical context: This repo has been around for five years and has been used, at various times, for at least three related proposals (each superseding the last), the first of which was a Service-Worker-exclusive "launch" event, then rebranding as "declarative link capturing" for a purely declarative launch system, and finally to a more generic "launch handler" allowing both a declarative or programmatic option, in either a foreground page or service worker.

The name "sw-launch" isn't appropriate any more, but on the other hand there are probably hundreds of incoming links to the sw-launch repo that would break if we renamed it. Have you done a similar scale of rename before in a WICG repo and would you recommend it again?

Since WICG is supposed to be a temporary staging area anyway, my preference would be to update as many things as possible to use the new name, which don't break the URL (e.g. change the "about" field in GitHub), but not rename the repo, and give it an appropriate name if/when it transitions out of WICG and needs a new URL anyway. Does that sound reasonable?

Yoav Weiss

unread,
Oct 20, 2022, 3:37:54 AM10/20/22
to Matt Giuca, Alan Cutter, blink-dev, Penelope McLachlan
On Thu, Oct 20, 2022 at 5:29 AM Matt Giuca <mgi...@chromium.org> wrote:
Hey Yoav,

On Wed, 19 Oct 2022 at 23:52, Yoav Weiss <yoav...@chromium.org> wrote:
Hey! Thanks for pushing this :)

On Tue, Oct 18, 2022 at 8:42 AM Alan Cutter <alanc...@chromium.org> wrote:

I went over the spec and filed a few issues. None of them seems blocking (as in, they won't change the API shape), but they'd help us achieve an interoperable specification.

Would it be possible for y'all to go over the issues list, close the ones that are no longer relevant, and then label ones that may contain any future compat risk, if any? (That is, issues that may change the API shape once resolved)

Aside: should the repo be renamed to "web-app-launch" or something similar?

It probably should!

Historical context: This repo has been around for five years and has been used, at various times, for at least three related proposals (each superseding the last), the first of which was a Service-Worker-exclusive "launch" event, then rebranding as "declarative link capturing" for a purely declarative launch system, and finally to a more generic "launch handler" allowing both a declarative or programmatic option, in either a foreground page or service worker.

The name "sw-launch" isn't appropriate any more, but on the other hand there are probably hundreds of incoming links to the sw-launch repo that would break if we renamed it. Have you done a similar scale of rename before in a WICG repo and would you recommend it again?

Since WICG is supposed to be a temporary staging area anyway, my preference would be to update as many things as possible to use the new name, which don't break the URL (e.g. change the "about" field in GitHub), but not rename the repo, and give it an appropriate name if/when it transitions out of WICG and needs a new URL anyway. Does that sound reasonable?

(None of this is critical for the intent)
I think it makes sense, but at the same time, we have handled renames in WICG in the past, through a combination of GH's redirects when a repo is renamed and the https://github.com/WICG/wicg.github.io repo.
If y'all want to rename, I think we can make it happen without breaking existing links. At the same time, if there's imminent adoption around the corner, we might as well only do this work once.

Alan Cutter

unread,
Oct 21, 2022, 2:20:23 AM10/21/22
to blink-dev, Yoav Weiss, blink-dev, pjmcl...@google.com, Matt Giuca, Alan Cutter
On Wednesday, 19 October 2022 at 11:52:32 pm UTC+11 Yoav Weiss wrote:
Hey! Thanks for pushing this :)

On Tue, Oct 18, 2022 at 8:42 AM Alan Cutter <alanc...@chromium.org> wrote:
I went over the spec and filed a few issues. None of them seems blocking (as in, they won't change the API shape), but they'd help us achieve an interoperable specification.
Thanks! There is definitely hand waviness in this spec, this is deliberate as it's describing the "end" of the launch pipeline where the launch "start" or "trigger" is decided by other specs/the user agent. I need to figure out how to word such open behaviours in specese.


Would it be possible for y'all to go over the issues list, close the ones that are no longer relevant, and then label ones that may contain any future compat risk, if any? (That is, issues that may change the API shape once resolved)
Marked most of the existing issues as future-api work (extensions to the current API).
Marked one as a potential compat risk: https://github.com/WICG/sw-launch/issues/48

Aside: should the repo be renamed to "web-app-launch" or something similar?
If old links can continue to work SGTM.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Alan Cutter

unread,
Oct 27, 2022, 11:01:13 PM10/27/22
to blink-dev, Alan Cutter, Yoav Weiss, blink-dev, pjmcl...@google.com, Matt Giuca
On Friday, 21 October 2022 at 5:20:23 pm UTC+11 Alan Cutter wrote:
On Wednesday, 19 October 2022 at 11:52:32 pm UTC+11 Yoav Weiss wrote:
Hey! Thanks for pushing this :)

I went over the spec and filed a few issues. None of them seems blocking (as in, they won't change the API shape), but they'd help us achieve an interoperable specification.
Thanks! There is definitely hand waviness in this spec, this is deliberate as it's describing the "end" of the launch pipeline where the launch "start" or "trigger" is decided by other specs/the user agent. I need to figure out how to word such open behaviours in specese.


Would it be possible for y'all to go over the issues list, close the ones that are no longer relevant, and then label ones that may contain any future compat risk, if any? (That is, issues that may change the API shape once resolved)
Marked most of the existing issues as future-api work (extensions to the current API).
Marked one as a potential compat risk: https://github.com/WICG/sw-launch/issues/48

Aside: should the repo be renamed to "web-app-launch" or something similar?
If old links can continue to work SGTM.
The rename has been done. The old GitHub links will redirect but the old spec link no longer works.
The draft spec is now at: https://wicg.github.io/web-app-launch/

Yoav Weiss

unread,
Oct 29, 2022, 12:09:07 PM10/29/22
to Alan Cutter, blink-dev, pjmcl...@google.com, Matt Giuca
On Fri, Oct 28, 2022 at 5:01 AM Alan Cutter <alanc...@chromium.org> wrote:
On Friday, 21 October 2022 at 5:20:23 pm UTC+11 Alan Cutter wrote:
On Wednesday, 19 October 2022 at 11:52:32 pm UTC+11 Yoav Weiss wrote:
Hey! Thanks for pushing this :)

On Tue, Oct 18, 2022 at 8:42 AM Alan Cutter <alanc...@chromium.org> wrote:
I went over the spec and filed a few issues. None of them seems blocking (as in, they won't change the API shape), but they'd help us achieve an interoperable specification.
Thanks! There is definitely hand waviness in this spec, this is deliberate as it's describing the "end" of the launch pipeline where the launch "start" or "trigger" is decided by other specs/the user agent. I need to figure out how to word such open behaviours in specese.


Would it be possible for y'all to go over the issues list, close the ones that are no longer relevant, and then label ones that may contain any future compat risk, if any? (That is, issues that may change the API shape once resolved)
Marked most of the existing issues as future-api work (extensions to the current API).
Marked one as a potential compat risk: https://github.com/WICG/sw-launch/issues/48

Aside: should the repo be renamed to "web-app-launch" or something similar?
If old links can continue to work SGTM.
The rename has been done. The old GitHub links will redirect but the old spec link no longer works.
The draft spec is now at: https://wicg.github.io/web-app-launch/

Added a redirect from the old link to the new one.
 


To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Yoav Weiss

unread,
Oct 29, 2022, 12:13:03 PM10/29/22
to Alan Cutter, blink-dev, pjmcl...@google.com, Matt Giuca
On Sat, Oct 29, 2022 at 6:08 PM Yoav Weiss <yoav...@chromium.org> wrote:


On Fri, Oct 28, 2022 at 5:01 AM Alan Cutter <alanc...@chromium.org> wrote:


On Friday, 21 October 2022 at 5:20:23 pm UTC+11 Alan Cutter wrote:
On Wednesday, 19 October 2022 at 11:52:32 pm UTC+11 Yoav Weiss wrote:
Hey! Thanks for pushing this :)

I went over the spec and filed a few issues. None of them seems blocking (as in, they won't change the API shape), but they'd help us achieve an interoperable specification.
Thanks! There is definitely hand waviness in this spec, this is deliberate as it's describing the "end" of the launch pipeline where the launch "start" or "trigger" is decided by other specs/the user agent. I need to figure out how to word such open behaviours in specese.


Would it be possible for y'all to go over the issues list, close the ones that are no longer relevant, and then label ones that may contain any future compat risk, if any? (That is, issues that may change the API shape once resolved)
Marked most of the existing issues as future-api work (extensions to the current API).
Marked one as a potential compat risk: https://github.com/WICG/sw-launch/issues/48

 Seems like the issue converges on leaving the existing behavior as is. Does that mean the risk is lowered here?

Also, I think it'd be good to address https://github.com/WICG/web-app-launch/issues/67 (and define the callers to the algorithm) before shipping.

Alan Cutter

unread,
Nov 2, 2022, 2:39:57 AM11/2/22
to blink-dev, Yoav Weiss, blink-dev, pjmcl...@google.com, Matt Giuca, Alan Cutter
On Sunday, 30 October 2022 at 3:13:03 am UTC+11 Yoav Weiss wrote:
On Sat, Oct 29, 2022 at 6:08 PM Yoav Weiss <yoav...@chromium.org> wrote:
On Fri, Oct 28, 2022 at 5:01 AM Alan Cutter <alanc...@chromium.org> wrote:
On Friday, 21 October 2022 at 5:20:23 pm UTC+11 Alan Cutter wrote:
On Wednesday, 19 October 2022 at 11:52:32 pm UTC+11 Yoav Weiss wrote:
Hey! Thanks for pushing this :)

On Tue, Oct 18, 2022 at 8:42 AM Alan Cutter <alanc...@chromium.org> wrote:
I went over the spec and filed a few issues. None of them seems blocking (as in, they won't change the API shape), but they'd help us achieve an interoperable specification.
Thanks! There is definitely hand waviness in this spec, this is deliberate as it's describing the "end" of the launch pipeline where the launch "start" or "trigger" is decided by other specs/the user agent. I need to figure out how to word such open behaviours in specese.


Would it be possible for y'all to go over the issues list, close the ones that are no longer relevant, and then label ones that may contain any future compat risk, if any? (That is, issues that may change the API shape once resolved)
Marked most of the existing issues as future-api work (extensions to the current API).
Marked one as a potential compat risk: https://github.com/WICG/sw-launch/issues/48
 Seems like the issue converges on leaving the existing behavior as is. Does that mean the risk is lowered here?
Yes, I consider any changes there to be future API extensions and the current behavior is fine as is.


Also, I think it'd be good to address https://github.com/WICG/web-app-launch/issues/67 (and define the callers to the algorithm) before shipping.
This is underway, 3 PRs are in review:
 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Alan Cutter

unread,
Nov 8, 2022, 9:57:02 PM11/8/22
to blink-dev, Alan Cutter, Yoav Weiss, blink-dev, pjmcl...@google.com, Matt Giuca
https://github.com/WICG/web-app-launch/issues/69 and https://github.com/WICG/web-app-launch/issues/67 spec issues have now been fixed.

Chris Harrelson

unread,
Nov 9, 2022, 11:37:19 AM11/9/22
to Alan Cutter, blink-dev, Yoav Weiss, pjmcl...@google.com, Matt Giuca
Thanks!
LGTM1

On Tue, Nov 8, 2022 at 6:57 PM Alan Cutter <alanc...@chromium.org> wrote:
https://github.com/WICG/web-app-launch/issues/69 and https://github.com/WICG/web-app-launch/issues/67 spec issues have now been fixed.

On Wednesday, 2 November 2022 at 5:39:57 pm UTC+11 Alan Cutter wrote:
On Sunday, 30 October 2022 at 3:13:03 am UTC+11 Yoav Weiss wrote:
On Sat, Oct 29, 2022 at 6:08 PM Yoav Weiss <yoav...@chromium.org> wrote:
On Fri, Oct 28, 2022 at 5:01 AM Alan Cutter <alanc...@chromium.org> wrote:
On Friday, 21 October 2022 at 5:20:23 pm UTC+11 Alan Cutter wrote:
On Wednesday, 19 October 2022 at 11:52:32 pm UTC+11 Yoav Weiss wrote:
Hey! Thanks for pushing this :)

On Tue, Oct 18, 2022 at 8:42 AM Alan Cutter <alanc...@chromium.org> wrote:
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4b8b2f31-207d-427d-9569-066c408322e2n%40chromium.org.

Mike Taylor

unread,
Nov 9, 2022, 11:37:47 AM11/9/22
to Chris Harrelson, Alan Cutter, blink-dev, Yoav Weiss, pjmcl...@google.com, Matt Giuca
LGTM2

Yoav Weiss

unread,
Nov 10, 2022, 1:32:14 AM11/10/22
to Mike Taylor, Chris Harrelson, Alan Cutter, blink-dev, pjmcl...@google.com, Matt Giuca
LGTM3 

Alan Cutter

unread,
Nov 10, 2022, 8:07:58 PM11/10/22
to blink-dev, Yoav Weiss, Chris Harrelson, Alan Cutter, blink-dev, pjmcl...@google.com, Matt Giuca, Mike Taylor
Thanks! I will aim to ship in M110.

On Thursday, 10 November 2022 at 5:32:14 pm UTC+11 Yoav Weiss wrote:
LGTM3 

On Wed, Nov 9, 2022, 17:37 Mike Taylor <mike...@chromium.org> wrote:
LGTM2

On 11/10/22 1:36 AM, Chris Harrelson wrote:
Thanks!
LGTM1

On Tue, Nov 8, 2022 at 6:57 PM Alan Cutter <alanc...@chromium.org> wrote:
On Wednesday, 2 November 2022 at 5:39:57 pm UTC+11 Alan Cutter wrote:
On Sunday, 30 October 2022 at 3:13:03 am UTC+11 Yoav Weiss wrote:
On Sat, Oct 29, 2022 at 6:08 PM Yoav Weiss <yoav...@chromium.org> wrote:
On Fri, Oct 28, 2022 at 5:01 AM Alan Cutter <alanc...@chromium.org> wrote:
On Friday, 21 October 2022 at 5:20:23 pm UTC+11 Alan Cutter wrote:
On Wednesday, 19 October 2022 at 11:52:32 pm UTC+11 Yoav Weiss wrote:
Hey! Thanks for pushing this :)

On Tue, Oct 18, 2022 at 8:42 AM Alan Cutter <alanc...@chromium.org> wrote:
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
Reply all
Reply to author
Forward
0 new messages