Declarative Link Capturing

[mgiuca]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Declarative Link Capturing (capture_links)
• Specification or proposal URL: https://github.com/WICG/sw-launch/blob/main/declarative_link_capturing.md
• Caniuse.com URL (optional): N/A
• Bugzilla URL (optional): N/A
• Mozillians who can provide input (optional):
• TAG review: https://github.com/w3ctag/design-reviews/issues/589
• Chrome Status: https://www.chromestatus.com/feature/5734953453092864

Other information

Extension to the Web App Manifest spec, adding a single new member capture_links, controlling the behaviour of the installed web application when the user clicks links within its scope from a web browser or another application in the OS.

[annevk]

Thoughts:

• Arbitrary does not seem great and opens the door to a lot of complex heuristics.
• What if you navigate a nested browsing context to a matching URL?
• There should be some caveats that ultimately this is user-configurable and that you cannot rely on there being a single instance open at most.
• You cannot avoid touching the HTML navigation stack even with this proposal.

[mgiuca]

Thanks for your points.

Thoughts:

• Arbitrary does not seem great and opens the door to a lot of complex heuristics.

(Assuming you refer to "if more than one exists, the user agent may choose one arbitrarily" for existing-client-navigate and existing-client-event.)

Possibly. The idea behind this is that if the app is using ECN or ECE, there will generally only be zero or one windows open anyway, so this clause doesn't come up (just pick the one open window). If the user overrides the link capturing behaviour and opens multiple windows, then later clicks a link letting the default behaviour take over, we will have to pick one of the windows.

I would rather that the heuristic for choosing a window be part of the browser, not the standard, so we can adapt it as necessary (i.e., I think it's part of the UI, not something the site should be able to mandate). The alternative is that we either say "choose the most recently opened one" or "choose the most recently focused one".

The general idea is that ECN or ECE are for developers who do not want full control over the link capturing, they just want a sensible default for an application that's only supposed to have one instance open at a time. If developers do want full programmatic control, that's what the proposed serviceworker mode is for (then you get to write JavaScript code to choose exactly which client to focus).

• What if you navigate a nested browsing context to a matching URL?

I guess we didn't say here, but I would expect it to not trigger link capturing logic.

• There should be some caveats that ultimately this is user-configurable and that you cannot rely on there being a single instance open at most.

Yes. We should say this explicitly. The user agent should always give the user the option to override this (e.g., right-click the link and say "open in new tab" (avoiding link capturing altogether) or "open in new app window" (performing link capturing but avoiding the existing client selection logic). You should always be able to select the app icon and open a second window.

[annevk]

Right, I'm worried that the heuristics might get complex and that applications might start to depend on them, especially with the event variant.