handle_links manifest field ✨

[diekus]

Hola TAG!

I’m requesting an early TAG review of web app link handling.

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. To achieve this, an installed application might want to register itself to handle links and create this seamless flow. From a UX perspective, it is desirable to give users choice on how they prefer the link to be opened, and it is important since it creates the cohesive and integrated experience mentioned previously.

• Explainer: https://github.com/WICG/pwa-url-handler/blob/main/handle_links/explainer.md
• Security and Privacy self-review: https://raw.githubusercontent.com/WICG/pwa-url-handler/main/handle_links/Security%20and%20Privacy%20Self-Review%20Questionnaire.md
• Primary contacts:
  • Diego Gonzalez (@diekus), Microsoft
  • Lu Huang (@LuHuangMSFT), Microsoft
  • Mandy Chen (@mandymsft), Microsoft
• Organization/project driving the design: Microsoft
• External status/issue trackers for this feature (publicly visible, e.g. Chrome Status): https://chromestatus.com/feature/5740751225880576

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): unknown
• Existing major pieces of multi-stakeholder review or discussion of this design:
• Major unresolved issues with or opposition to this design: N/A
• This work is being funded by: Microsoft

You should also know that this work is the evolution of the URL Handling feature. We have iterated on the idea of how URL handling should work on installed web apps, creating a clearer separation of roles between handle_links and scope_extensions .

The explainer to the previous “shape” of this feature is listed here: https://github.com/WICG/pwa-url-handler/blob/main/explainer.md.

The TAG review for the previous “shape” of this feature is: #552 .

Related APIs: scope_extensions: https://github.com/WICG/manifest-incubations/blob/gh-pages/scope_extensions-explainer.md

We'd prefer the TAG provide feedback as:
💬 leave review feedback as a comment in this issue and @-notify : @diekus, @luhuang

✨

[etnos]

Hi @diekus and @luhuang !

Please answer these questions to help us better understand the proposal.

1. After a PWA is installed, is it possible to change the handle_links mode? E.g., the mode is set to "all" and at some point, I want to set it to "none" or "auto".

2. Is it a new behavior or it is possible to achieve it via SW?

Thanks!

[LuHuangMSFT]

Hi @etnos

1. After a PWA is installed, is it possible to change the handle_links mode? E.g., the mode is set to "all" and at some point, I want to set it to "none" or "auto".

handle_links should be treated as a hint or suggestion from the app to the UA. As such, it's not something that the end user needs to interact with directly. The UA may implement link handling settings for apps that the end user can control. Those settings need not correspond 1-1 with these options. The user interacts with the setting of the installed app and not the hint from the app.

For our first implementation, we intend to use handle_links to decide the initial setting for an app after install. These settings may look like: [handle link in app client directly | prompt user to handle link in app | never handle link in app]. Afterwards, the user may override this setting.

2. Is it a new behavior or it is possible to achieve it via SW?

This is a new behavior. There is no previous behavior that captures the same information from the app to the UA. It should not be achieved with a service worker because 1. it is a declarative API suited to the manifest, 2. it is not expected to change often or depend on other state, and 3. it is useful even when no SW is found.

[cynthia]

The user interacts with the setting of the installed app and not the hint from the app.

This is a bit unclear - does this assume that the user agent provide a mechanism to set this?

Afterwards, the user may override this setting.

Could you clarify if this is something that the application is expected to provide or the user agent? What happens if the application decides to not provide a way to set this?

[cynthia]

See also: WICG/pwa-url-handler#42

[torgo]

Hi @diekus have you achieved any clarity on where this might end up after WICG? Maybe Web Applications working group?

[LuHuangMSFT]

The user interacts with the setting of the installed app and not the hint from the app.

This is a bit unclear - does this assume that the user agent provide a mechanism to set this?

I can clarify. The proposed handle_links manifest field is something that the user agent may choose to consider. If the user agent makes use of this information, it may also want to allow users to control or override the effects through user settings. I don't think such settings need to be standardized so it's outside of the scope of this proposal.

Afterwards, the user may override this setting.

Could you clarify if this is something that the application is expected to provide or the user agent? What happens if the application decides to not provide a way to set this?

The user agent would provide the user setting mechanism if it does provide it. It is not required to provide one.

[torgo]

Hi @diekus @LuHuangMSFT we're just reviewing today at our F2F. We're largely happy with the initial proposal. We're slightly concerned about the possibility that the user might get an unexpected user experience - and to what the balance should be between user choice and author choice. Overall we would like to see how this experiment turns out so we would appreciate the opportunity to re-review with some early implementation feedback. Also as mentioned we would like to see this work on a trajectory to the web applications working group. ✨