Installer: Do not write "URL Protocol" to the ChromeHTML registry entry.

chrome/installer/util/shell_util.cc

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 //
 // This file defines functions that integrate Chrome in Windows shell. These
 // functions can be used by Chrome as well as Chrome installer. All of the
 // work is done by the local functions defined in anonymous namespace in
 // this class.
 
 #include "chrome/installer/util/shell_util.h"
@@ skipping 279 matching lines @@
       }
     }
 
     // File association ProgId
     base::string16 chrome_html_prog_id(ShellUtil::kRegClasses);
     chrome_html_prog_id.push_back(base::FilePath::kSeparators[0]);
     chrome_html_prog_id.append(GetBrowserProgId(suffix));
     entries->push_back(new RegistryEntry(
         chrome_html_prog_id, dist->GetBrowserProgIdDesc()));
     entries->push_back(new RegistryEntry(
-        chrome_html_prog_id, ShellUtil::kRegUrlProtocol, base::string16()));

[gab, 2014/09/12 11:43:15]

From
https://code.google.com/p/chromium/codesearch#chromium/src/chrome/installer/u...
this appears to be intended to hook functionality in IE/Explorer. WDYT?

[grt (UTC plus 2), 2014/09/12 13:59:41]

If http://msdn.microsoft.com/library/ie/aa767914.aspx is to be believed, "URL
Protocol" should be added to the HKCR\<proto> key where <proto> names an URL
scheme (e.g., "mailto"). I can't think of any reason to put this value on any
keys except those for URL schemes.

It looks like ShellUtil::RegisterChromeForProtocol doesn't do this registration.
I wonder if Chrome is actually being launched from IE when clicking on links
it's the default handler for.

[Matt Giuca, 2014/09/12 23:49:24]

I'll do some testing in IE on Monday. (I didn't realise this was for IE's
benefit, but for other apps like Start -> Run that say "launch this URL".) It
doesn't make sense for a web browser to respect this setting when the user
clicks on a HTTP link; I would imagine IE only honours this when clicking on a
link it can't handle (like a "steam://" URL).

[grt (UTC plus 2), 2014/09/13 03:27:38]

Exactly. I wonder what would happen if Chrome is registered as the default
protocol handler for, say, webcal://. Will clicking those links in IE launch
Chrome? My guess is that the answer is no by accident. Would you find a way to
trigger navigator.registerProtocolHandler so that Chrome registers itself as the
handler for a protocol, then follow a link for that protocol in IE to see what
happens? This is a great find. I think you may have come across a legitimate bug
in rPH.

[Matt Giuca, 2014/09/15 00:52:01]

No, it works perfectly:

1. Go here: http://www.lookout.net/test/handler/
2. Next to "Run ad hoc test", change "mailto" to "web+foo" and click the button.
3. In IE, type into the URL bar "web+foo:bar".

It will correctly open Chrome and navigate to
http://www.lookout.net/foo=web%2Bfoo%3Abar.

ShellUtil::MakeChromeDefaultProtocolClient is called from
navigator.registerProtocolHandler.

[grt (UTC plus 2), 2014/09/15 13:55:18]

Awesome, thanks for confirming.

-    entries->push_back(new RegistryEntry(
         chrome_html_prog_id + ShellUtil::kRegDefaultIcon, icon_path));
     entries->push_back(new RegistryEntry(
         chrome_html_prog_id + ShellUtil::kRegShellOpen, open_cmd));
     if (set_delegate_execute) {
       entries->push_back(new RegistryEntry(
           chrome_html_prog_id + ShellUtil::kRegShellOpen,
           ShellUtil::kRegDelegateExecute, delegate_guid));
     }
 
     // The following entries are required as of Windows 8, but do not
@@ skipping 1975 matching lines @@
     // are any left...).
     if (free_bits >= 8 && next_byte_index < size) {
       free_bits -= 8;
       bit_stream += bytes[next_byte_index++] << free_bits;
     }
   }
 
   DCHECK_EQ(ret.length(), encoded_length);
   return ret;
 }