Add Manifest option for specifying browser app picker behavior

[raymeskhoury]

Problem: When a user clicks a link, it may be able to be handled by many different apps installed on the system. For example, clicking a link to reddit may be able to handled by:

1. The default browser in which the link was clicked
2. The reddit PWA that's installed (via a launch event handler)
3. The reddit Android app that's installed

Browsers can implement UI which allows users to choose which app they want to use to handle to link (an "app picker"). PWA's may want to give different hints to the browser about whether or not they can handle different links into their app, e.g. -Some apps may want the browser to always show the app picker for link clicks into their app, to give the user the option of which app to open the link with -Some apps may want the browser to always directly open link clicks in their PWA without showing the app picker -Some apps may never want the browser to open certain links in their app. For example, Facebook may have an app, but they are also an authentication provider and may not want redirects to login links to be opened in the app (e.g. https://www.facebook.com/v3.2/dialog/oauth)

The app picker needs to show up before the launch event is fired so apps need a way to define these behaviors up-front.

Proposal: Add a manifest entry to specify these hints. link_capturing_preference: "never" - tell the browser that this app never handles link clicks into itself and the app picker shouldn't list the app as an option. No launch event should ever be fired for link clicks to the app. link_capturing_preference: "ask_user" - tell the browser that the app does handle link clicks, but the browser should ask the user whether to handle the link first. This would be the default setting if not specified. link_capturing_preference: "always" - tell the browser that the app prefers to handle link clicks without the user being shown an app picker. Browsers are still free to override this and show a dialog if they choose.

By default these options apply to all links in the scope of the app. However apps could also define these options for more narrow scopes inside itself:

link_capturing_preference: [
  { url: "/", preference: "always" },
  { url: "/v3.2/dialog/oauth", preference: "never" }]

@benfredwells @dominickng @fallaciousreasoning thoughts?

[fallaciousreasoning]

I think we could change "Android App" to "Native App" (e.g. a Windows Store app on Windows, a Mac App on Mac) to make the issue a little more generic.

I'd be tempted to only provide two options: default and never. I think it would make things a little more obvious to developer how things work (ask_user is actually ask until the user picks a default, then do that) and I'm skeptical that we'd want to let apps specify always without some kind of user interaction. It seems like something we'd be more likely to decide browser wide (maybe as a browser experiment), and default gives us a little more wriggle room here.

I take it we would apply the preference for the most specific scope? What about duplicates?

link_capturing_preference: [
     { "url": "/ihavenoideawhatimdoing", "preference": "always" },
     { "url": "/ihavenoideawhatimdoing", "preference": "never" },
]

It's not super important but we could take the first, last or most restrictive?

Also, is there a reason we're not going for a dictionary as opposed to a list of key value pairs? Are there any other properties we could conceivably add here?

link_capturing_preference: {
    "/": "always",
    "/v3.2/dialog/oauth": "never"
}

(this would also fix the duplicates problem, but only I don't think we should do it if there's a chance we'll want to add new properties).

[fallaciousreasoning]

Thinking about it, I don't think this proposal is strictly part of launch events. Launch events has a solution for not opening in a new window/continuing the navigation: Don't do that.

This seems more like a separate (but semi related) proposal, relating more to intent handling.

link_capturing_preference is about which application to use while launch events are about which window in an application to use.

[fallaciousreasoning]

Random thought: This solves the problem of opt out for PWAs, but what about on other platforms (e.g. native, or android/linux on ChromeOS).

Consider: I have the Facebook Android app installed, but not the PWA and I've set all facebook.com links to open in the Facebook app (can I even do this?)? How does the app tell us which links should be opted out? Does this also break login flows?

Maybe there's an existing mechanism for doing this with Android apps (I don't know much about Android)?

Sorry for all the spam :/

[fallaciousreasoning]

Disregard the previous, apparently Android intents should let you filter out pages :)

[dominickng]

@fallaciousreasoning for clarity, there's no way to exclude particular pages using Android intent filters. Instead, if you don't want to capture everything under a particular domain, you need to carefully specify what path prefixes you do and don't want to capture.

[raymeskhoury]

and I'm skeptical that we'd want to let apps specify always without some kind of user interaction.

Android apps have this notion which is why I added it as an option (see https://developer.android.com/training/app-links). It's called "Android App Links". This is the thing that would allow a developer to say "if my youtube PWA is installed, by default open youtube links in my PWA using a launch event".

How does the app tell us which links should be opted out? Does this also break login flows? Maybe there's an existing mechanism for doing this with Android apps (I don't know much about Android)?

Yep, see the link above. They specify intent filters using a set of paths as @dominickng mentioned.

[raymeskhoury]

Also, is there a reason we're not going for a dictionary as opposed to a list of key value pairs? Are there any other properties we could conceivably add here?

Good idea, that might be a better approach :)

[fallaciousreasoning]

@dominickng Do we want to do this as part of Intent Handling?

[dominickng]

@fallaciousreasoning do you mean, don't add a manifest option, and just handle it at the OS level?

[fallaciousreasoning]

No, I think we need the manifest option. This just seems kind of orthogonal to launch events

[alancutter]

I believe the handle_links proposal is the right place to cover this use case.