ChromeHTML URL Protocol Handler does not work as expected
Reported by 69kjw...@gmail.com, Sep 11 2014
UserAgent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.62 Safari/537.36 Steps to reproduce the problem: 1. IN IE8, IE10, run dialog, or in an Office doc, Outlook, create a hyperlink/type in an address of ChromeHTML://www.bbc.co.uk 2. Press enter or launch the hyperlink 3. Chrome will open but without opening the passed web page What is the expected behavior? I would expect chrome to open with the passed web address in a new tab. It should work form all applications and should not require any characters which are disallowed in web addresses. What went wrong? Chrome opens but at the home page or new tab page (whichever is set as the default. Did this work before? N/A Chrome version: 29.0.1547.62 Channel: stable OS Version: Windows 7/Windows XP Flash Version: Shockwave Flash 11.8 r800 I have removed the quotes around the passed parameter in the Protocol Handler command registry entry, and this enables it to work in IE, Run dialog, Office docs if you use the following format (note the space after //: ChromeHTML:// www.bbc.co.uk This does not work in Outlook as Outlook. The registry now looks like this: Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ChromeHTML] @="Chrome HTML Document" "URL Protocol"="" [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ChromeHTML\DefaultIcon] @="C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe,0" [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ChromeHTML\shell] [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ChromeHTML\shell\open] [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ChromeHTML\shell\open\command] @="\"C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe\" -- %1" The issue also occurs in Chrome v31.
Sep 16 2014,
69kjwest@, would you verify with chrome latest stable M37 build and update your findings.
Nov 25 2014,
I just tried this protocol handler and it appears to still be broken. I tested on: Version 39.0.2171.62 beta-m (64-bit)
Mar 4 2015,
I verified this is still a problem in Chromium build version Version 43.0.2322.0 (64-bit) on Windows 7.
Jun 12 2015,
Unable to repro this issue on Windows 7 for Google Chrome Stable Version - 43.0.2357.124 Screen-recording is attached. @69kjwest: Could you please update your Google Chrome to Latest Stable Version - 43.0.2357.124 and let us know your observations, which would help us in triaging it further. Thank you.
Jun 12 2015,
Your screen share didn't show the link or where you executed it from. But I can still reproduce this on two different machines running Windows 7 with Chrome Beta. Chrome launches, but it only opens to chrome://newtab, it doesn't load the link. Windows 7 with Chrome Version 44.0.2403.39 beta-m (64-bit) and Windows 7 with Chrome Version 44.0.2403.39 beta-m I'm sure it would be the same with stable. Screencast attached.
Nov 9 2015,
This is still broken in version 46. Do you think it will be fixed? It will help us transition a web application off of IE7 & 8 to Chrome.
Dec 10 2015,
Cc'ing gab@ for help in investigating this further.
Dec 18 2015,
69kjwest@ could you please let us know are you still facing the issue on latest stable ? Request you please check the issue on latest stable 47.0.2526.106 and update the thread if the issue still persists. Thanks,
Jan 15 2016,
correct the time on Kelly's google map
Mar 1 2016,
Closing this issue as there is no response from the original reporter, In case if this issue still persists on latest chrome versions please feel free to raise a new issue.
May 6 2016,
This is still an issue. I just verified it on 50.0.2661.94 m in a clean install and an upgrade on windows 10 and windows 7. This is very important for users in mixed browser environments that require opening some links in Chrome while leaving the default browser as IE. This is a very common scenario in corporate environments. This issue is also trivially easy to verify, so closing it out because the original reporter is gone is poor form at best.
Aug 25 2016,
Having this issue on Chrome 50.0.2661.102 m. Corporate install, updates disabled by administrator. Editing [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ChromeHTML\shell\open\command] in regedit, the REG_SZ value is: "C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" -- "%1" Fiddling with it, I finally got it to work with the following form: C:\Progra~2\Google\Chrome\Application\chrome.exe -- %1 Would be lovely if this could be fixed.
Oct 4 2016,
This is still an issue and you don't need the original issue owner to test this and determine for yourself that it is still broken after being reported two years ago. I am suer this is a one line code change for you all so please fix it.
Oct 4 2016,
I don't understand what's being requested here. ChromeHTML is Chrome's ProgId, it's not meant to be a protocol. If you want to launch Chrome via Run... make it the default handler for the http protocol and it will directly handle say "http://example.com" or "www.example.com" (see https://support.google.com/chrome/answer/95417?hl=en). For more details about how Chrome registers itself and its supported protocols, see https://www.chromium.org/developers/installer.
Oct 4 2016,
The issue is that if you work in a company that has locked down the default HTTP protocol to say IE, and you want to force pages to open in Chrome instead, it is super handy to be able to do: chromehtml://www.mysite.com instead of http://www.mysite.com That's what the REGEDIT entry of [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ChromeHTML] @="Chrome HTML Document" "URL Protocol"="" does. It used to work, now it doesn't. Thanks, Spencer
Oct 4 2016,
ChromeHTML is Chrome's progid not a protocol if a version of Windows ever allowed chromehtml://example.com to work that wasn't by design. Furthermore, as of Windows 8, it's impossible to programatically become default for a protocol. As the machine owner you can however, invent your own protocol and have it launch Chrome if you wish.
Oct 4 2016,
Please reference my comment #14 from Aug 25. There is in fact a registry key that works to recognize chromeHTML:\\ . The issue is not that it is missing or this feature is lacking, but that the syntax in the REG_SZ value seems to be incorrectly matched to Chrome's ability to parse the %1 argument. If you edit the registry key and remove the quotes as I noted, then chromeHTML:\\ links work just fine (Windows 7). I interpret this ticket as simply asking if this "bug" can be fixed by either correcting the registry key when Chrome next installs/updates, or changing Chrome to recognize a quote-wrapped url argument when launched via the command line. Thanks
Oct 4 2016,
Aaaah, I see, then yes this bug makes sense. I'll try to have a look at why that argument is quoted (and either remove the quotes if it doesn't have to be or teach Chrome to handle quoted URLs).
Oct 5 2016,
Stumbled on https://msdn.microsoft.com/en-us/library/windows/desktop/cc144175(v=vs.85).aspx for something else just now. It clearly states that "You should always use quotation marks with arguments such as "%1" that are expanded to strings by the Shell, because you cannot be certain that the string will not contain a space." so the quotes are correct (although there shouldn't be spaces in a URL, this could also be used to launch say a PDF from the local file system). So Chrome has to handle quoted URLs on the command-line IMO. @grt: does that make sense to you?
Oct 5 2016,
That was also my conclusion to the best of my recollection. It's been a while :) Spencer Yeh (650) 804-0926
Oct 6 2016,
I've verified that Chrome's command line parsing code does properly strip out quotes. We need to figure out what is different when Chrome is launched through this mechanism. I don't think it's a matter of making Chrome handle quoted URLs (try chrome.exe "http://www.google.com").
Oct 6 2016,
Hmmm that does indeed work and so does chrome.exe -- "http://www.google.com" per the registered command: "C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" -- "%1" When I try this from the Run prompt on Win10 though: chromeHTML:// www.google.com I get a Windows popup saying: "You'll need a new app to open this" so I'm still skeptical this is meant to work.
Oct 6 2016,
Nov 18 2016,
We have a current scenario where we have some legacy IE7 users that also have Chrome installed on their PC's. They need IE7 for legacy Intranet applications. This kind of link would be *ideal* for us to simply redirect these [often non-technical] users to the right browser. This would be a really useful feature.
Dec 7 2016,
Hi, This is still an issue in Version 55.0.2883.75 m Thanks.
Dec 16 2016,
This is still an issue for us and allowing us to use the protocol chromeHTML would be very helpful to launch intranet sites that only work with Chrome since changing browser default cannot be done.
Dec 21 2016,
I've updated my blog post, Google for some reason deleted a registry key which broke the last fix: https://www.adamfowlerit.com/2015/05/how-to-launch-a-url-in-google-chrome/#comment-6941
May 18 2017,
I did a procmon trace a found out that Outlook never trying to reqquery for HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ChromeHTML\* Instead it always queries in the following order 1. HKEY_CURRENT_USER\SOFTWARE\Classes\ChromeHTML\* 2. HKEY_CLASSES_ROOT\ChromeHTML\*
May 18 2017,
I forgot to mention my Test Setup: Windows Srv 2008 R2 in a Citrix Terminal Server Environment Outlook 2010 (32-Bit) Chrome 58 (64-Bit)
Jul 6 2017,
Regarding comment #30: HKEY_CLASSES_ROOT is a virtual hive which is an amalgam of keys from HKLM\Software\Classes and HCKU\Software\Classes. So that second query is hitting the HKLM key you referenced.
Oct 9 2017,
Hi Folks My name is Patrick Kettner, and I work at Microsoft on the Edge team. We have seen a number of people hit this issue and wanted to work with the Chrom(e/ium) teams to get it working as expected. firstname.lastname@example.org mentioned in #18 that it was not an intentional design choice to have chromehtml work as a way to open chrome. If the team DOES want a custom URI pattern similar to what is done on iOS/android, we do offer this - https://msdn.microsoft.com/en-us/library/aa767914(v=vs.85).aspx If there are questions with what has to be done, please let me know. Would really love to get this one solved :]
Nov 11 2017,
Here's what I'm guessing has happened: - At one point Chrome had special code for handling ChromeHTML:// links AND there was a bug in the registry key missing the quotes. - Links like ChromeHTML://foo.com would work - At some point someone decided (or accidentally) removed the ChromeHTML code without touching the registry key - Now links like the above were broken. - Some clever folks found that, due to the registry missing quotes, they could hack around this by adding the space after ChromeHTML://. Then chrome would be run with two arguments, "ChromeHTML://" (ignored) and "foo.com" (opened as http://foo.com). - Now someone has fixed the registry to add the missing quotes, so the clever workaround is broken. So I see two options: 1) This is behavior we want, so we should re-add the code that treats chromehtml scheme just like http (maybe rewrite in the command line handling to avoid the rest of chrome having to know about this bogus scheme), OR 2) Delete the registry key entries making it clear this is not a feature we support. I'll try to search the code history to see if I can find evidence of this chromehtml handling code being removed and why.
Nov 13 2017,
Looks like support for launching via "ChromeHTML:..." was removed in issue 5825 for security reasons. Maybe those reasons no longer apply since Chrome now always includes "--" in the command line written to ...\ChromeHTML\shell\open\command. The things to do here if we want to go down this road are: 1. Add the empty "URL Protocol" string value to the registry in shell_util.cc's GetProgIdEntries. This will tell Windows that ChromeHTML is an URL protocol and that chrome.exe should be launched to handle it. 2. Teach Chrome to understand its own ProgID as an URL protocol (note HasDeprecatedArguments in chrome_main_delegate.cc). It would be nice to know what problems the old code had (see "gives us nothing but trouble" comment in r13384). Was it limited to issue 5825 , or were there other troubles? As for how to handle ChromeHTML: URLS -- I'm not sure what the best route is -- strip "ChromeHTML:" during command line parsing so that the rest of the string is interpreted as-is (so ChromeHTML:ftp://blah.com would use ftp as the protocol), or maybe treat "ChromeHTML:" as a synonym for "https:".
Nov 20 2017,
It's not clear if we want to go down this road. Feel free to reopen this issue if there are additional developments in this area.
Jan 22 2018,
Sorry, it wont be fixed because you don't know if you want to allow the ChromeHTML code still? For what reason(s) wouldn't you want to go down this road?
Jun 21 2018,
I got the following error: 1. Create a new Shortcut on Desktop to "http://www.google.com" 2. Pull it on the Google Chrome icon in the task bar. Now the link is pinned. 3. Right click on taskbar icon > Left click on pinned link. => Internetlink cannot be opened because of missing "ChromeBHTML" protocol handler. But i found it in registry. Please fix that problem. Same works with Internet Explorer. Chrome Beta 68.0.3440.33 64bit
Sign in to add a comment