Ben: Is there a component for registerProtocolHandler ?

Yep :)

It seems this works well on macOS.

Unable to triage this issue from TE-End, hence adding a "TE-NeedsTriageHelp" for further triage.

Verified issue on Linux, although mailto: links seemed fine. Is there anything in particular you're trying to do with this that will help us assign a priority?

I try to call people :)
We've got a web interface for our hardware phones that registers as tel: URL link handler, and by using that I can click on tel: URLs in all applications on my desktop including Thunderbird's address book.

I switched to Firefox to make this work, so it's not that important for me since I found a workaround.

This seems to be something in content. What is happening is that tel: urls, when specified on the command line, end up having 'http://' prepended to them somewhere in chrome::Navigate, before it comes up in the resource throttler that the protocol handler system intercepts. This does not happen with mailto: urls.

+Loader team who might know where this would be happening / know who should look at it.

+kinuko who I think knows about loading.

Kinuko - any ideas about #8 (or if not, know who would?)?

Looks like more about navigation related logic-- nasko: perhaps you might have better idea about what's happening there?

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

It is still important.