UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.117 Safari/537.36

Steps to reproduce the problem:
1. Register an external protocol, eg test://
2. Trigger that from chrome, eg test://foo
3. Check the "Remember my choice"
4. Click Launch
5. Unregister the protocol (eg by deleting the registry key for it)
6. Trigger the protocol from chrome again
7. Notice that the Windows "You'll need a new app to open this" dialog is triggered

What is the expected behavior?
Chrome should produce the normal behaviour for triggering an unregistered protocol, which is to do nothing, and not try to launch  the protocol.

What went wrong?
Chrome tried to launch the protocol even though it doesn't exist and produced inconsistent behaviour with the protocol having never been remembered before.

Did this work before? No 

Chrome version: 66.0.3359.117  Channel: stable
OS Version: 10.0
Flash Version: 

This is happening because Chrome records whether the protocol is BLOCK or DONT_BLOCK after the "Remember my choice" is ticked, but if the protocol has never been seen before, or the user had ticked "Remember my choice", then the first thing it does is validate whether the protocol exists. If the protocol doesn't exist, then Chrome does nothing at all and the protocol silently fails.

We are using the "Chrome does nothing at all" behaviour to detect whether the protocol exists (in lieu of a proper JS API for this) and trigger an Download Installer dialog on the webpage. We use onBlur() to find out when the browser has defocussed, meaning that our app ran successfully (see https://github.com/ismailhabib/custom-protocol-detection/blob/master/protocolcheck.js). However, the Windows "You'll need a new app to open this" dialog also triggers this defocus behaviour. This means that any user who uninstalls our app (and therefore the protocol), and ticked "Remember my choice", will never be presented with the Download Installer dialog ever again.

We believe we have a workaround, which is to alter the Chrome Preferences file in %localappdata% during our app's uninstall process, but we feel that altering a user's Chrome files is morally dubious & unreliable, and would much prefer consistent behaviour from the external protocol handler (even better would be a JS API to find out if handlers exist, or an error result if the protocol failed, but that seems like a much more complicated feature request).