Reporter@ - Thanks for filing the issue...!!

Could you please provide a sample URL/test file to test the issue from TE-end.
This will help us in triaging the issue further.

Thanks...!!

I have the same issue since Chrome Updated to Version 63.0.3239.84.
Our Customers Call our Desktop Scanning Application 100s of times a day and now are now getting prompted every time which they are calling us about, and complaining ever since this update went into effect.

Deleted: TEST_vsiprotocol.html 695 bytes

TEST_vsiprotocol.html 695 bytes View Download

Change the Path and EXECUTABLE name in the REG File to any EXE on your desktop, like Notepad or Calculator.

Same issue on Windows 10 with Chrome 63.0.3239.84, after a full Chrome reset. Customers are also complaining.

Matt, can you take a look?

Hmmm... I can't reproduce this on Mac, Windows or Linux.

Note I'm not testing a "phpstorm" scheme, but different external protocols ("steam" and "itunes"). Seems to be working as intended. Perhaps there is a more specific step we're missing, if we're getting multiple reports. Alternatively, this could be a M63 issue that was later fixed. (I am testing with Canary.)

Aside: I'm confused about the screenshot in the original report; it looks like Windows' external protocol dialog, not Mac.

A CL I can think of that might be responsible is r503375 (landed in M63). This CL does something very similar to this bug report: it ignores the "Remember" setting for the block choice. Whereas this bug is about the "Remember" setting being ignored for the allow choice. Could have some bad interaction.

But at present I am unable to reproduce...

> (I am testing with Canary.)

Actually this is false... I was testing with an old 62 when I couldn't reproduce. I just tested on Windows with 63 (stable), 64 (beta) and 65 (canary). Oddly, I *cannot* reproduce with 63.0.3239.108, but I *can* repro with 64 and 65.

Not sure why two of the reports are coming in for 63. This seems to be a regression some time in between 63 or 64.

The details are:
- The "excluded_schemes" key is present in the Preferences file, but is an empty dict. This is very strange, because it's supposed to be populated with a bunch of default keys even on first run.
- Choosing "Remember" and pressing "Run" is supposed to add an entry to "excluded_schemes", with a value of false. It does not add the value.
- If you manually add a false value (e.g., {"steam": false}) to "excluded_schemes", it will be respected. So there is no problem with honoring the setting; rather something is failing to write any settings there.

The versioning is messing with my head... I could not repro on Linux 64, but I *can* repro on a fresh build with Linux 65. So I'll look deeper on here.

Indeed, reverting r503375 fixes it. I also figured out why I was unable to repro on some 63 and 64 installs: this bug only affects new profiles created *after* r503375. So any user who was already using Chrome before 63 seems to be unaffected, but if you create a new profile in 63 onwards, you are unable to remember any protocols.

This is to do with the excluded_schemes pref key. Before r503375, excluded_schemes is created with a bunch of default values. After r503375, excluded_schemes is created empty. If excluded_schemes has all of its default values in it (from an older version of Chrome), then new values are able to be written there. But if it's empty, then no new values are written. Bizarre. Now to dive into the code.

Weird: it seems this was an existing bug that was tickled by r503375 which removes all of the default schemes (which explains why excluded_schemes now starts out empty). Even if you go back to 62, if you manually delete all of the excluded_schemes, you are unable to write new ones. So there is some much older bug which prevents schemes from being written if there are none to begin with.

Root-cause bug was introduced in r448213 (M58), which migrated prefs from Local State to Preferences. This code added a check that prevents writing to Preferences if excluded_schemes was empty, in order to avoid writing to Preferences pre-migration.

This migration code has been removed (also in r503375) so it is safe to remove this check. Thanks +dominickn for analysis.

CL: https://crrev.com/c/831317

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/6aaf64152ea8c778758cd4f85b954a1a278a3159

commit 6aaf64152ea8c778758cd4f85b954a1a278a3159
Author: Matt Giuca <mgiuca@chromium.org>
Date: Mon Dec 18 23:26:42 2017

Fix not being able to remember external protocol handler Allow state.

Fixes a regression introduced in r503375 where pressing 'Always open
these types of links in the associated app' would have no effect, when
opening an external protocol handler. This bug only affects new profiles
created after M63.

The root cause was actually not r503375, but r448213, which added a
check preventing new entries from being written if the list was empty
(in order to avoid writing to Preferences pre-migration). This
migration code has been removed (also in r503375) so it is safe to
remove this check.

Bug:  788431 
Change-Id: I39bbeb604dad081a2b27dd231b126a7cb525be81
Reviewed-on: https://chromium-review.googlesource.com/831317
Reviewed-by: Ben Wells <benwells@chromium.org>
Commit-Queue: Matt Giuca <mgiuca@chromium.org>
Cr-Commit-Position: refs/heads/master@{#524854}
[modify] https://crrev.com/6aaf64152ea8c778758cd4f85b954a1a278a3159/chrome/browser/external_protocol/external_protocol_handler.cc
[modify] https://crrev.com/6aaf64152ea8c778758cd4f85b954a1a278a3159/chrome/browser/external_protocol/external_protocol_handler_unittest.cc

I'd like to merge this to M64, because it's a user-facing regression (a feature stopped working; the UI for it still exists but it does nothing). It's a one line fix, modulo tests and indentation changes.

I will be on vacation from tomorrow, so I am appointing dominickn@ to land the merge if it gets approved. Dom, if you want to test this on Canary, please note that you must *create a new Chrome profile* before following the repro steps above. Thanks!

 Issue 796056  has been merged into this issue.

This bug requires manual review: M64 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), kbleicher@(ChromeOS), abdulsyed@(Desktop)

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

Has this been verified and confirmed in Canary?

It hasn't yet rolled to Canary. I will update this bug once it has.

This has been on Canary now and I've manually verified the fix. Requesting merge. :)

 Issue 784071  has been merged into this issue.

Approving merge for M64. Branch:3282

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/86b28a1abdac75b68aea0863cfb5ec3b7f6f832a

commit 86b28a1abdac75b68aea0863cfb5ec3b7f6f832a
Author: Matt Giuca <mgiuca@chromium.org>
Date: Thu Dec 21 22:07:56 2017

Fix not being able to remember external protocol handler Allow state.

Fixes a regression introduced in r503375 where pressing 'Always open
these types of links in the associated app' would have no effect, when
opening an external protocol handler. This bug only affects new profiles
created after M63.

The root cause was actually not r503375, but r448213, which added a
check preventing new entries from being written if the list was empty
(in order to avoid writing to Preferences pre-migration). This
migration code has been removed (also in r503375) so it is safe to
remove this check.

Bug:  788431 
Change-Id: I39bbeb604dad081a2b27dd231b126a7cb525be81
Reviewed-on: https://chromium-review.googlesource.com/831317
Reviewed-by: Ben Wells <benwells@chromium.org>
Commit-Queue: Matt Giuca <mgiuca@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#524854}(cherry picked from commit 6aaf64152ea8c778758cd4f85b954a1a278a3159)
Reviewed-on: https://chromium-review.googlesource.com/841302
Reviewed-by: Dominick Ng <dominickn@chromium.org>
Cr-Commit-Position: refs/branch-heads/3282@{#326}
Cr-Branched-From: 5fdc0fab22ce7efd32532ee989b223fa12f8171e-refs/heads/master@{#520840}
[modify] https://crrev.com/86b28a1abdac75b68aea0863cfb5ec3b7f6f832a/chrome/browser/external_protocol/external_protocol_handler.cc
[modify] https://crrev.com/86b28a1abdac75b68aea0863cfb5ec3b7f6f832a/chrome/browser/external_protocol/external_protocol_handler_unittest.cc

We've merged to M64. This bug is fixed on Canary and the next M64 updates should carry the fix as well.

 Issue 797303  has been merged into this issue.

I tested using Canary Version 65.0.3310.2 (Official Build) canary (64-bit), and it works as it did before.

Thank You.

 Issue 786961  has been merged into this issue.

 Issue 799313  has been merged into this issue.

I am a product director and our web app uses the Chrome Protocol every time a users engages our external client program (in this case opens an Office document). We have many users with this issue and are hoping to know when this will be fixed.

#33: this issue will be fixed in the next release of Chrome, scheduled for release this week.

You can test it by using any prerelease version of Chrome, i.e. the beta, dev, or canary channels.

I can confirm the issue is resolved in Chrome Version 64.0.3282.119 (Official Build) (64-bit) on Windows 7.

That's good for me, too. Awesome.

Hallelujah! Confirming the bug has been fixed in Chrome Version 64.0.3282.119 (Official Build) (64-bit) on macOS 10.13.2. Well done guys.

When is it going to be released (64.0.3282.119?

Currently using Chrome Version 63.0.3239.132 (Official Build) (64-bit) and it's not working yet.

For those who say it's not working for them, update via the help menu to 64.0.3282.119 and this fixed the problem for me. Thanks!

I have updated around 45 desktops to Chrome 64.0.3282.119 and i have a 100% success rate. 

Make sure you re-launch Chrome and possibly re-start your Computer if re-launch does not work for you.

After applying Chrome 64.0.3282.140 chrome is not percent decoding the uri.

For example till Chrome 63 clicking on alert:Hello%20World was resulting in below command
"C:\Program Files\Alert\alert.exe" "alert:Hello World"

But after applying Chrome 64 the decoding is not happening and the percent encoded string is getting passed to the desktop application like below
"C:\Program Files\Alert\alert.exe" "alert:Hello%20World"

Is this an expected behavior or a bug? in IE it works the other way i.e. IE is percent decoding the uri.

Yes I think that is expected due to the fix for  issue 785809  (sorry I think access to that bug is restricted).

mgiuca - please correct me if I'm wrong.

#44 is correct. (Sorry, we'll make  https://crbug.com/785809  public soon once the fix rolls out.) This is irrelevant to the bug we're talking about here, but since that other bug is private, very briefly, we now pass URL parameters through to external protocols with escaping. This matches the behaviour in Firefox. We're aware it doesn't match IE or Edge.