Intent to Prototype: Web app handle links

[Lu Huang]

Contact emails

luig...@microsoft.com, lu...@microsoft.com, mandy...@microsoft.com

Explainer

https://github.com/WICG/pwa-url-handler/blob/main/handle_links/explainer.md

Summary

The 'handle_links' app manifest entry aims to allow registration of installed web applications as link handlers, to grant them the possibility of opening links like their native counterparts. This feature allows developers to opt-in/opt-out of link handling behavior for their applications.

Blink component

UI>Browser>WebAppInstalls

Motivation

When clicking on a link, the default behavior is that the browser will open and navigate to the specified URL. However, if a compatible application is installed, a user might prefer to have that application launch and "open" said link. This is the case for native apps that range from media consumption to productivity, where if installed, will open when clicking on a link with related content. This is generally the preferred way to interact with the referenced content.

Initial public proposal

https://github.com/WICG/manifest-incubations/pull/14

TAG review

- 

TAG review status

Pending

Risks

The proposed feature relies on origin and app navigation scope based protections to mitigate risk.

Interoperability and Compatibility

Gecko: No signal
WebKit: No signal
Web developers: No signals

Debuggability

Most issues that could arise can be investigated using the DevTools Application pane and information visible from chrome://web-app-internals. More debug UI can be added to DevTools if necessary.

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

No

Flag name

WebAppHandleLinks

Requires code in //chrome?

True

Tracking bug

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

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://www.chromestatus.com/feature/5740751225880576 

[Fabrice Desre]

Hi,

This functionality looks useful as a user agent feature, but I'm not
convinced that it should be added in the manifest.

The default behavior when clicking on a link should be to open it in the
app that the link is in scope for. The user agent can let users override
that behavior with whatever policy it implements. Here you want to give
that agency to app developers instead: I wonder how many apps will chose
something else than "all" - do you have any insight?

Best,

Fabrice

On 9/30/21 3:42 PM, 'Lu Huang' via blink-dev wrote:
> *Contact emails*
>
> luig...@microsoft.com
> <mailto:luig...@microsoft.com>, lu...@microsoft.com
> <mailto:lu...@microsoft.com>, mandy...@microsoft.com
> <mailto:mandy...@microsoft.com>
>
> *Explainer*
>
> https://github.com/WICG/pwa-url-handler/blob/main/handle_links/explainer.md
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FWICG%2Fpwa-url-handler%2Fblob%2Fmain%2Fhandle_links%2Fexplainer.md&data=04%7C01%7CLu.Huang%40microsoft.com%7Ce145d8c96a274e3378e908d98387e38e%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637685442093438023%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=DlNgLJhW9AZlkbb6azZTXX4JlyhV0AapBFUb8yvoJLY%3D&reserved=0>
>
> *Summary *

>
> The 'handle_links' app manifest entry aims to allow registration of
> installed web applications as link handlers, to grant them the
> possibility of opening links like their native counterparts. This
> feature allows developers to opt-in/opt-out of link handling behavior
> for their applications.
>

> *Blink component *
>
> UI>Browser>WebAppInstalls
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.chromium.org%2Fp%2Fchromium%2Fissues%2Flist%3Fq%3Dcomponent%3AUI%253EBrowser%253EWebAppInstalls&data=04%7C01%7CLu.Huang%40microsoft.com%7Ce145d8c96a274e3378e908d98387e38e%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637685442093438023%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=xOAUgv%2BglsjqhdbXHEExC07Rj0nznR7rXWpsjDYf%2F%2Bc%3D&reserved=0>
>
> *Motivation *

>
> When clicking on a link, the default behavior is that the browser will
> open and navigate to the specified URL. However, if a compatible
> application is installed, a user might prefer to have that application
> launch and "open" said link. This is the case for native apps that range
> from media consumption to productivity, where if installed, will open
> when clicking on a link with related content. This is generally the
> preferred way to interact with the referenced content.
>

> *Initial public proposal*
>
> https://github.com/WICG/manifest-incubations/pull/14
> <https://github.com/WICG/manifest-incubations/pull/14>
>
> *TAG review *
>
> - 
>
> *TAG review status *
>
> Pending
>
> *Risks*

>
> The proposed feature relies on origin and app navigation scope based
> protections to mitigate risk.
>

> *Interoperability and Compatibility*
>
> /Gecko/: No signal
> /WebKit/: No signal
> /Web developers/: No signals
>
> *Debuggability*

> Most issues that could arise can be investigated using the DevTools
> Application pane and information visible from
> chrome://web-app-internals. More debug UI can be added to DevTools if
> necessary.

> *
> * *Is this feature fully tested by web-platform-tests
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%2F%2B%2Fmaster%2Fdocs%2Ftesting%2Fweb_platform_tests.md&data=04%7C01%7CLu.Huang%40microsoft.com%7Ce145d8c96a274e3378e908d98387e38e%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637685442093448017%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=tEGPtJqlAlUtw5DXnSvOiAeJ49EMbag4SonQUpVsimo%3D&reserved=0>?
> *
>
> No
>
> *Flag name *
>
> WebAppHandleLinks
>
> *Requires code in //chrome? *
>
> True
>
> *Tracking bug *
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=1254457
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.chromium.org%2Fp%2Fchromium%2Fissues%2Fdetail%3Fid%3D1254457&data=04%7C01%7CLu.Huang%40microsoft.com%7Ce145d8c96a274e3378e908d98387e38e%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637685442093448017%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=XsUKVAUtmOuBGQVHn0UQGpu06qqQphrNARkPa9U6crU%3D&reserved=0>
>
> *Estimated milestones *
>
> No milestones specified
>
> *Link to entry on the Chrome Platform Status *
>
> https://www.chromestatus.com/feature/5740751225880576
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.chromestatus.com%2Ffeature%2F5740751225880576&data=04%7C01%7CLu.Huang%40microsoft.com%7Ce145d8c96a274e3378e908d98387e38e%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637685442093458017%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=of9id2DPlwoQJVyMly9VTO%2BQ%2BYnXIePMacvd4O8AmsA%3D&reserved=0> 
>
> --
> 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
> <mailto:blink-dev+...@chromium.org>.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/46f3577a-5f59-4f83-84c4-0e460d7621bcn%40chromium.org
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/46f3577a-5f59-4f83-84c4-0e460d7621bcn%40chromium.org?utm_medium=email&utm_source=footer>.

[Lu Huang]

Hello Fabrice, 

Thank you for your comments. Here are some thoughts about the options:

• We are proposing that "auto" is the default behavior if the manifest entry is not found. This allows user agents to implement and enable link handling for web apps without app developer input. 
• There was a past Chrome experiment that opened app windows by capturing link navigations - it concluded that app developers wanted more control over what URLs are handled and also over the app launch behavior. We have also seen feedback from developers that they need to be able to exclude specific URLs or paths from link handling even through they are in scope. 
• We think it is possible that if developers had finer control of the app navigation scope (perhaps with a more expressive syntax), separate configuration to adjust which in-scope URLs are link handled might not be necessary. If it is decided in the future that additional configuration is necessary, a "custom" option can be added to "all", "none", and "auto". 
• The `none` option allows app developers to disable link handling behavior until they have the control they need (through URL configuration, launch behavior configuration, etc.). It also allows them to make necessary app changes to incorporate the link handling experience on their own schedule. 

Let me know if the above addresses your concern. 

Regards,

Lu Huang