Why Chrome on Linux shows "External protocol request" dialog for unknown protocol?

Question

I am creating a custom protocol handler for Google Chrome on Linux. My link looks like this:

<a href="myprotocol:someargument">Trigger my app with param</a>

I have noticed that if 'myprotocol:' is not registered (my app not installed), Google Chrome on Linux displays "External Protocol Request" dialog and tries to use xdg-open:

While on other OS, such as Windows 10 and OS X El Capitan nothing is displayed if protocol is not registered.

I have also verified that Firefox works consistently for unknown protocols on Windows, OS X and Linux - nothing is displayed.

Chrome behavior on Linux is quite confusing for users.

Any idea why Chrome on Linux (I was testing on Ubuntu 14.04) acts differently from any other OS and web browsers?

Answer 1

The issue is really that if Chrome lacks a local protocol handler then it wants to use the handler configured in the user's environment. No two OSes provide exactly the same API to launch a default handler. Figuring out what this program would be before actually launching it is not even a clear API on Windows or Linux.

Both the "Mac" and Windows implementations end up knowing which external application is ultimately responsible for the protocol and therefore are able to suppress unhandled calls without issuing a call warning. But the windows implementation is actually a kludge that relies on observations of the windows registry on existing versions on windows. This type of API violation is more dangerous on Linux where many flavors have very different forks of the related settings tools.

It is actually considered a bug that Windows and OsX don't issue an alternate warning that they've called nothing, so you may want to comment here if you think that is the right behavior.

Here is my observation of how the 3 systems work based on the current source:

Linux

In Linux, when you register protocol handlers with the (window) system, you do something like:

xdg-settings set default-url-scheme-handler myprotocol evolution.desktop

Now, the application evolution is responsible for your protocol and anything can call:

 xdg-open myprotocol:...

To now open evolution on these links. The other OSes have similar mechanisms, but may not have an external program as the call stub.

This is nice and abstract and knowing/saying the external app you are calling is xdg-open prevents much complication in the linux implementation. But it is not exactly the information the user probably wants. Getting that information would require using xdg-settings instead and risks being incorrect if there is or ever will be a way to conditionally override the default handler in some flavors of this system.

Windows

In the Windows handler, apparently you can just go snooping around in the registry and then make an educated guess as to what calling the api is going to actually do. Technically, chrome has to do this since the way it opens external programs is through a system API, so there is not an external stub like xdg-open to refer to in the warning.

Mac

In the "mac" handler, there is a proper API to ask about the app your specific URL will launch, so chrome does, then if the application name the empty string it can completely drop the call before generating the warning.