Add Manifest option for specifying browser app picker behavior

[raymeskhoury]

Problem: When a user clicks a link in a web page, 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. A reddit PWA that's installed (via a launch event handler)
3. The reddit Android app that's installed
4. A native app that handles reddit links

Browsers/OS's 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 PWAs may want the browser to always show the app picker for link clicks into their PWA, to give the user the option of which app to open the link with.
-Some PWAs may want the browser to always directly open link clicks in their app without showing the app picker. This is analogous to the behavior of Android App Links.
-Some PWAs 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. Note that the browser is always free to override the hint.
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. The link click should never launch the PWA or fire a launch event.
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 link clicks in the scope of the app. However apps could also define these options for more narrow scopes inside itself:

link_capturing_preference: [
  { "/" : "always" },
  { "/v5.5/dialog/oauth" : "never" }]

/cc @benfredwells @dominickng @fallaciousreasoning

[raymeskhoury]

@reillyeon

[dominickng]

-Some PWAs may want the browser to always show the app picker for link clicks into their PWA, to give the user the option of which app to open the link with.

Could you clarify a case where an app might want this behaviour?

-Some PWAs may want the browser to always directly open link clicks in their app without showing the app picker. This is analogous to the behavior of Android App Links.

To my mind, this feels like the behaviour most apps would want.

-Some PWAs 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)

Are there any other examples aside from OAuth providers that might want this exclusion behaviour?

[fallaciousreasoning]

As per the thread here, is there any reason to avoid:

link_capturing_preference: {
    "/": "always",
    "/v5.5/dialog/oauth": "never"
}

and use the list of objects syntax?

[kenchris]

Everything is a preference, even scope - they browser can always override behavior - or not implement it. Not sure why we need the _preference

[kenchris]

@dominickng's comments makes this more sounds like a whitelist or a blacklist.

[kenchris]

FYI, ask_user in other spec like Permissions we call this prompt - actually there we used granted, denied and prompt which seems to fill well here as well

[reillyeon]

Would making it a list of exclusions under "scope" still satisfy the need?

link_capturing_excluded: [
    "/v5.5/dialog/oauth"
]

[raymeskhoury]

-Some PWAs may want the browser to always show the app picker for link clicks into their PWA, to give the user the option of which app to open the link with.
Could you clarify a case where an app might want this behaviour?

Twitter may want the user to be able to install their PWA without link clicks always opening in the PWA. They may want the user to be able to decide whether it opens in the browser, in the android app or in the PWA.

To my mind, this feels like the behaviour most apps would want.

Agreed, but only if the PWA is the primary experience

Are there any other examples aside from OAuth providers that might want this exclusion behaviour?

That's the main example.

As per the thread here, is there any reason to avoid:
link_capturing_preference: {
"/": "always",
"/v5.5/dialog/oauth": "never"
}
and use the list of objects syntax?

No, I think your suggestion is better :)

Everything is a preference, even scope - they browser can always override behavior - or not implement it. Not sure why we need the _preference

Good question. Thinking more about it:

1. If the PWA says don't capture, I think it should never be captured
2. If the PWA says ask the user, I think it should always ask the user (user can save the preference)
3. If the PWA says always open, I think it's up to the browser to decide but we recommend always opening

For (3) it is really a hint by the app but I think the user agent is still in the best place to decide what's best for the user.

@dominickng's comments makes this more sounds like a whitelist or a blacklist.

We thought about it being a blacklist but I think this behavior is more flexible and more aligned with a platform like Android which effectively provides all of these options.

FYI, ask_user in other spec like Permissions we call this prompt - actually there we used granted, denied and prompt which seems to fill well here as well

I'm flexible with terminology. 'prompt' does seem better than 'ask_user'. granted/denied I'm not so sure about.

Would making it a list of exclusions under "scope" still satisfy the need?

It would solve the oauth problem but I don't think it provides the flexibility to tell the browser the apps preference with regard to capturing. Some apps will /want/ the user to be in control. Other apps will /want/ to always handle links themselves if possible.

Possibly it makes sense to break it out into 2 different features. link_capturing_excluded and a separate option which is a preference of how to handle captures. The original proposal seems a bit cleaner to me though.

[kenchris]

With terminology I think I would call it link_capture (as capture is used in other places across the platform).

[kenchris]

Even if I set prompt and there is only one option, will it then still prompt or just follow through?

[fallaciousreasoning]

+1 to link_capture

Can there be just one option? My understanding was that if the app isn't installed, we'd just navigate normally. If the app is installed we have two options:

1. Open in the app window
2. Do the navigation in the browser window

At which point, we can prompt :)

[aarongustafson]

I’m in favor of seeing this proposal revised per the comments (link_capture, the configuration object, etc.).

[mgiuca]

Hello folks,

I actually don't think I saw this before (this discussion happened while I was AFK). But I've just typed up a proposal that I think covers it, so linking to it here (and, tentatively, assigning myself).

Declarative link capturing

This is more or less an evolution of what @raymeskhoury proposed a year ago, only without the ability to fine-grained apply it to sets of URLs. I believe the latter is covered by @LuHuangMSFT's URL Handlers proposal.