I'm not too concerned in how this is resolved :-) Just wanted to make a point I use a Mac currently, as if it were ChromeOS with an escape hatch to run native software every now and then. I live in the browser. I think there are many people who live this way, but I bring no data to say if this is more common -- it could be the majority of users have set up a native mail client, and like the default behavior.

I found the double-diamond icon in webmail clients to be unintuitive. I was pleased to know it exists, and it has made things easier. :-)

I'm going to clarify this slightly into a request.

The current RPH prompt is just an icon that appears in the address bar.  This is hard to notice, especially for wide windows.

We already have some idea of how apps should be able to (progressively) ask for permissions when those permissions would be useful, without disrupting you.  This prompt long predates those efforts and I imagine there's more we could do here to allow sites like Gmail to be slightly more aggressive about prompting for mailto: handling without it letting every site on the web be annoying.

Don't know what component this should go in.  Someone please help triage :/

Thank you for the FYI. I think what's being discussed here doesn't need any changes to web platform APIs or Blink, so I'm removing the CustomHandlers component. If there's work we can do for you please feel free to reapply the label. Thanks!

+CCing ainslie@ since this may be more a "browser side UX design" issue and I don't know whom the right owner is.  (See comment 2 for a brief problem overview.)

@5: I'm gonna reapply the label once, in hopes you can help clarify some things.  (You may be right that ultimately this isn't Blink-side work, I'm not sure.)

* What are the heuristics for when pages can prompt to register protocols, and how we show those prompts to the user?  Is it just, right now any page can ask at any time and we always prompt in the same way (via an address bar icon and no bubble)?
* For capabilities we expose progressively today like "add to homescreen", what do the web APIs look like?  Based on the answers to that, if we wanted to allow pages with high site engagement to be more aggressive in their RPH prompting, would we need any web API changes to better facilitate this?

> What are the heuristics for when pages can prompt to register protocols, and how we show those prompts to the user?  Is it just, right now any page can ask at any time and we always prompt in the same way (via an address bar icon and no bubble)?

Yes. From Blink's point of view, we don't stop pages calling the API, we just notify browser that the API was called. These make landfall in the browser in WebContentsImpl::OnRegisterProtocolHandler and it looks like the policy is in ui/Browser::RegisterProtocolHandler--put a chit in the omnibox.

> For capabilities we expose progressively today like "add to homescreen", what do the web APIs look like?

There's no web API for add to homescreen, it's a toast which depends on site engagement metrics. Ben, who's a good person to engage with questions like this?

> Based on the answers to that, if we wanted to allow pages with high site engagement to be more aggressive in their RPH prompting, would we need any web API changes to better facilitate this?

I don't think so. I don't know much about browser but I'm guessing you'd consult the SiteEngagementService in Browser::RegisterProtocolHandler and depending on the SiteEngagementScore decide what flair to show.

I'm going to take the label off again just to get this out of my team's triage queue. I think this is a great idea and wish you well in your work. Happy to help if there's anything specific we can do to help!

Adding Ballista and A2HS folks, this is very relevant for both of these projects.

You could imagine a flavour of the app banner being used for this: once a site passes a certain engagement cutoff, we respond to the handler request by showing a prompt to the user. Could we also include a site in desktop web share if it's advertised that it can handle protocols?

Also, I presume this would be a desktop-only behaviour? I don't think we actually do anything regarding protocol handlers on Android currently (though perhaps we should in this new PWA land).

Stepping back for a moment - is there any reason not to just automatically accept RPH for sites with high enough engagement and skip the whole prompt / accept step in the first place?

@10: If I have Yahoo and Gmail accounts and use both, will they both fight for the ability to handle mailto:?

+maxwalker@ and I were just chatting about whether handler UI could be a candidate for his new "anchored toast" explorations (and move management out of the omnibox-RHS and into Page Info with other origin-scoped things). It's also interesting to me from an A2HS perspective. 

The problem is RPH currently only has a single registration for each protocol, so we can't auto-accept based on engagement (otherwise as soon as you got enough engagement with yahoo.com it will clobber your gmail.com registration).

Eventually I'd like this to be a picker UI (and rolled in with whatever we come up with for Ballista); then we could use engagement, A2HS, etc.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Archiving given the lack of activity. Feel free to reopen if you have concrete ideas.