New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 413236 link

Starred by 14 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Nov 2017
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug

Sign in to add a comment

ChromeHTML URL Protocol Handler does not work as expected

Reported by, Sep 11 2014

Issue description

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://
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 //:
This does not work in Outlook as Outlook.

The registry now looks like this:

Windows Registry Editor Version 5.00

@="Chrome HTML Document"
"URL Protocol"=""

@="C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe,0"



@="\"C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe\" -- %1"

The issue also occurs in Chrome v31.
Labels: Needs-Feedback
69kjwest@, would you verify with chrome latest stable M37 build and update your findings.

Comment 2 by, 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)

I am using Chrome build Version 40.0.2214.115 m (64-bit)  on Windows 7 and it is still broken.  Please let me know when this is fixed as I have a project that requires opening a URL in Chrome and this would be uber-helpful  
I verified this is still a problem in Chromium build version Version 43.0.2322.0 (64-bit) on Windows 7.
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.
954 KB Download

Comment 6 by, 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)


Windows 7 with Chrome Version 44.0.2403.39 beta-m

I'm sure it would be the same with stable.

Screencast attached.

1.6 MB Download

Comment 7 Deleted

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.

Comment 9 by, Dec 10 2015

Labels: -Needs-Feedback
Cc'ing gab@ for help in investigating this further.
Labels: Needs-Feedback
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.

correct the time on Kelly's google map
downloads for google maps 1-14-16.txt
851 KB View Download
Labels: -Needs-Feedback
Status: WontFix (was: Unconfirmed)
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.
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. 
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.
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.  

Comment 16 by, 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 "" or "" (see

For more details about how Chrome registers itself and its supported protocols, see
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:


instead of

That's what the REGEDIT entry of

@="Chrome HTML Document"
"URL Protocol"=""

does.  It used to work, now it doesn't.


Comment 18 by, Oct 4 2016

ChromeHTML is Chrome's progid not a protocol if a version of Windows ever allowed chromehtml:// 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.
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. 


Comment 20 by, Oct 4 2016

Status: Assigned (was: WontFix)
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).

Comment 21 by, Oct 5 2016

Stumbled on 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?
That was also my conclusion to the best of my recollection. It's been a while :)

Spencer Yeh
(650) 804-0926

Comment 23 by, 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 "").

Comment 24 by, Oct 6 2016

Hmmm that does indeed work and so does

chrome.exe -- ""

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:

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.

Comment 25 by, Oct 6 2016

Components: Internals>Installer
Owner: ----
Status: Unconfirmed (was: Assigned)
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.

This is still an issue in Version 55.0.2883.75 m

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.
I've updated my blog post, Google for some reason deleted a registry key which broke the last fix:

Comment 30 by, May 18 2017

I did a procmon trace a found out that Outlook never trying to reqquery for 


Instead it always queries in the following order



Comment 31 by, 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)
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.
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. 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 -

If there are questions with what has to be done, please let me know. Would really love to get this one solved :]
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:// 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 "" (opened as
 - 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.

Comment 35 by, 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'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

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: would use ftp as the protocol), or maybe treat "ChromeHTML:" as a synonym for "https:".
Status: WontFix (was: Unconfirmed)
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.
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?
I got the following error:
1. Create a new Shortcut on Desktop to ""
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