[+benwells, +meacer]:  Looks like you guys own the ExternalProtocolHandler?  Not sure who else would be reasonable to direct this to - platform_util.h doesn't seem to have any owners.  Suppose it could also be related preliminary changes for PlzNavigate, so include navigation label as well.

PlzNavigate is not on 59 stable, has only been on Canary and Dev. Adding asanka@ for downloads behavior, in case there have been changes in that area that could be affecting the behavior.

Indeed it's not, but the non-PlzNavigate path was significantly changed while preparing to get PlzNavigate out the door.

Indeed it was changed. M55 is quite a while ago, so let's add Needs-Bisect and see if we can find when approximately it changed. I won't be able to do it in the next week or two, help is appreciated. 

Also, adding clamy@ explicitly.

Is this a regression?

The default action for any top level navigation that doesn't result in a response with a content type not understood by the renderer is to download it. It sounds like the behavior is WAI?

Asanka:  This is about the case where the mime type is recognized by the underlying OS, in which case we should (I assume) be passing the file (URL?) to the registered OS-level handler for that mime type.

#7: Invoking the underlying OS to open a file happens after the file is downloaded and only if there's an explicit user request to open the file or if the user has configured the file type to be opened automatically. On Linux, files are opened via 'xdg-open' which should work correctly as long as the filename has a recognized extension.

In the general case, the browser doesn't -- and shouldn't -- invoke xdg-open on a response even if there's a registered handler for its MIME type. At least not without explicit configuration and user consent.

Or am I misunderstanding the issue? :-)

This isn't an external protocol handler thing, as that is about handling links with different schemes like magnet:. These are regular downloads with a mime type.

Did this ever work in the way requestd? I don't think Chrome ever opens downloaded files that have handlers for their mime types, it just downloads them. You can then double click the downloaded file if you want.

You're right.  I had been thinking this was the magic scheme case, not the launch-based-on-mime type case.  Which would make this a pure downloads issue, not a navigation one, and working as intended, unless trying to run the file from Chrome doesn't run xdg-open.

OP: Does Chrome behave the way you want if you set .torrent as a file type that always opens? You can do so by downloading a .torrent file, and picking "Always open files of this type" from the download shelf context menu.

If the resulting behavior is what you are looking for, then this is all WAI. I don't think Chromium should have a special case for .torrent file. Though this shouldn't prevent a distribution from pre-populating the "download.extensions_to_open" preference  so long as the security trade-off has been considered.

That said, I'll defer to the current downloads owners.

It does behave as expected. I was under the impression that the default was for files to be opened. Thanks for the quick investigation and resolution.

Thanks for the followup!  Going to go ahead and close this.

How about open Telegram (https://telegram.org/) mime association: 
tg://resolve?domain=spbmetro

xdg-open tg://resolve?domain=spbmetro - worked

Chromium 60.0.3112.113 (Developer Build) Ubuntu 17.04 (64-bit) didn't open that uri tg://resolve?domain=spbmetro

And some many more other association not working. Although everything worked before. Broken after upgrade to version 58.