Intent to Extend Experiment: Declarative Link Capturing for PWAs

[Alan Cutter]

Contact emails

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

Explainer

https://github.com/WICG/sw-launch/blob/master/declarative_link_capturing.md

Specification

None

Summary

New Web App Manifest member to control what happens when the user navigates to a page within scope of an installed web app.

This feature introduces the "capture_links" member, an enumeration allowing the customization of link capturing behaviour, allowing sites to:

- Automatically open a new PWA window when the user clicks a link to their app.

- Have a "single window mode" like mobile apps.

Blink component

UI>Browser>WebAppInstalls

Search tags

pwa, link capturing

TAG review

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

TAG review status

In progress

Risks

Interoperability and Compatibility

Very small, since any browser not implementing this will just fall back to the standard behaviour, which is to navigate to links in a browser tab.
This member is also forwards compatible as it can accept a list of behaviours, older browsers will bypass any new ones that are added later. Gecko: No signal

Edge: Strong positive, this compliments their efforts for url_handlers.

WebKit: No signal

Web developers: No signals

Reason this experiment is being extended

A new API shape, Launch Handling, has evolved from the current spec work on Declarative Link Capturing and URL Handlers. Transition doc.

This extension is being requested to enable existing uses of the DLC experiment transition over to the Launch Handling API once it is ready for experimentation.

Previous experiment timeline: M90 to M93

Requested extension timeline: M94 to M97

Ongoing technical constraints

None

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

Not supported on Android, their window model doesn’t make sense for “new-client”.

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

No

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5734953453092864

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/2ZnA1IrSpS8

Intent to experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/q6ivDcvAJwQ/m/XTlva-lGBQAJ

This intent message was generated by Chrome Platform Status.

[Yoav Weiss]

It may make sense to reach out for signals at some point. https://bit.ly/blink-signals

 

Web developers: No signals

Don't you have developers already participating in the OT?

 

Reason this experiment is being extended

A new API shape, Launch Handling, has evolved from the current spec work on Declarative Link Capturing and URL Handlers. Transition doc.

That seems like a significant change. Would it make sense to send out a separate intent to experiment, to make that part clearer?

 

This extension is being requested to enable existing uses of the DLC experiment transition over to the Launch Handling API once it is ready for experimentation.

I think we can have different intents, but still converge on the same experiment tokens, to avoid churn for existing users. +Jason Chase, is that actually correct?

 

Previous experiment timeline: M90 to M93

Requested extension timeline: M94 to M97

Ongoing technical constraints

None

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

Not supported on Android, their window model doesn’t make sense for “new-client”.

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

No

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5734953453092864

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/2ZnA1IrSpS8

Intent to experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/q6ivDcvAJwQ/m/XTlva-lGBQAJ

This intent message was generated by Chrome Platform Status.

--
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/CANJJ2Cn7vN6hgras59Sn4%3DksdueFxrtatZLm7fFDo5uSpwSQoA%40mail.gmail.com.

[Alan Cutter]

Will be reaching out for signals on the Launch Handling API instead as it develops.

 

 

Web developers: No signals

Don't you have developers already participating in the OT?

Sorry, should have updated this. Strong positive from existing clients using DLC, unfortunately I can't point to any public statements here.

 

 

Reason this experiment is being extended

A new API shape, Launch Handling, has evolved from the current spec work on Declarative Link Capturing and URL Handlers. Transition doc.

That seems like a significant change. Would it make sense to send out a separate intent to experiment, to make that part clearer?

Sorry it wasn't clear. This extension is not intended for the Launch Handling API, that will be a separate experiment request later once it's ready. This extension is intended to create an overlap between the DLC and LH experiments so existing DLC users can transition over to LH.

[Yoav Weiss]

LGTM to extend M94-M97

[Jason Chase]

Likely a moot point now, but...

Assuming you mean different intents = different trials shown in the OT console, it's not possible to use the same tokens. The name used in the tokens has to be unique across trials.

[Yoav Weiss]

OK, thanks! That's useful info (for next time).

[Alan Cutter]

Request to extend M97 experiment end date to avoid breaking sites while transitioning to the new launch_handler API.

 - The launch_handler experiment has been approved for M97-M102 but due to implementation issues will start in M98.

 - To allow clients to migrate over to launch_handler seamlessly we need to keep the DLC behavior available until existing users have had a chance to update to M98.

 - To cover the February M98 Chrome OS rollout this extension request is to go up to 2022-03-31 (assuming ~1 month to roll out to a majority of users).

 - To avoid burn-in risk we will remove DLC from M98. This is the same strategy that the Digital Goods API experiment took for their v2 migration.

Previous experiment timeline: M90 to M93 Approved extension timeline: M94 to M97 Requested extension timeline: Up to 2022-03-31 but only for M97 browsers and earlier.

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

[Alan Cutter]

Friendly ping.

[Alex Russell]

LGTM1

[Alex Russell]

API OWNERS just discussed, and we also decided that this intent only needs a single vote (rather than 3). You're good to go!

[Alan Cutter]

Brilliant, thanks!

[Alan Cutter]

Request to extend the M97 end date for this origin trial from 2022-03-31 by 3 months to 2022-06-30.

There are still clients running M97 (especially in enterprise environments) that can't yet make use of the replacement launch_handler API (added in M98). Our analysis suggest an additional 3 months is sufficient for them to transition over smoothly.

API burn in risk: Low; the DLC API trial was removed in M98 and cannot be revived, its full removal is guaranteed as a matter of time based on client populations updating to M98+.

[Alan Cutter]

Amendment: The lag of M97 clients for this API is predominately seen in education rather than enterprise.

[Yoav Weiss]

Hey Alan,

As this is an exceptional request, I believe this requires 3 LGTMs.

The risk present here is that we'd be creating some breakage risk from terminating the OT ~3 months down the line. Weighing this risk compared to the inherent OT risk we're already exposed to, it doesn't seem like the 3 months extension would significantly increase it. The fact that the main users for this are in the education sector makes me speculate that an extension would reduce breakage risk, as many of those are likely to be on their (north hemisphere) summer break. 

Therefore, I believe an extension is reasonable.

LGTM1

Brilliant, thanks!

LGTM1

Friendly ping.

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

[Mike Taylor]

Yoav's reasoning sounds good to me. LGTM2.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWZVZNDz5DMzx77qW4YQaFQu4BrFRyBQt%2BbUe8EPMOv6Q%40mail.gmail.com.

[Chris Harrelson]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d950d311-0088-4de3-f2c0-0e246f92d5ba%40chromium.org.

[Alan Cutter]

Thanks again!

Brilliant, thanks!

LGTM1

Friendly ping.

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANJJ2Cn7vN6hgras59Sn4%3DksdueFxrtatZLm7fFDo5uSpwSQoA%40mail.gmail.com.

--
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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWZVZNDz5DMzx77qW4YQaFQu4BrFRyBQt%2BbUe8EPMOv6Q%40mail.gmail.com.

--
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.