Custom URI Protocol Handler does not work
Reported by
sh...@help-me.kr,
Dec 18 2017
|
|||
Issue descriptionChrome Version : 65.0.3288.0 URLs (if applicable) : custom URIs such as magnet: Other browsers tested: N/A What steps will reproduce the problem? (1) Register custom URIs from Windows registry (see https://stackoverflow.com/questions/7087728/custom-protocol-handler-in-chrome) (2) Launch registered custom URI from Headless Chrome What is the expected result? All of the above works well in normal(no-headless) Chrome (with no --headless flag), Application should be launched and a process should be forked. What happens instead? No results, even a target process is not forked. Please provide any additional information below. Attach a screenshot if possible. This happens on Windows 10, version 1709.
,
Dec 18 2017
Could this be because the custom protocol handler URL is now being converted when previously it wasn't? I just found that in beta/dev, my custom protocol url is being encoded when it wasn't previously (and it still works in Stable v63.0.3239.108!!!). Naturally, my client handler didn't decode it and now it doesn't work with the newly encoded URI. Now I'm scrambling to add this but if this change isn't stopped/delayed, we are heading into meltdown mode as thousands of my end-user machines will need my changed delivered ASAP.
,
Dec 19 2017
,
Dec 19 2017
FYI, here's the defect I entered for URI encoding that may be related to this: https://bugs.chromium.org/p/chromium/issues/detail?id=795919
,
Jan 23 2018
This issue is out of TE-Scope for triaging as issue is related to Headless. Tagging with TE-NeedsTriageHelp label. Could someone from Internals>Headless team have a look at this issue.
,
Feb 8 2018
I am also experiencing this issue. Custom protocol that is used to open Quotes in QuoteWerks. quotewerks://opendocument/?RecGUID=1BB5E638BFD54549A984A9D52916E35C&Tab=3 This url works in M$ Edge, and Firefox, but not in Chrome.
,
Mar 13 2018
Experiencing the same issue with application protocol hyperlinks being escaped since 64.0.3282.186.
,
Nov 12
Wrote a proof for this bug: https://f5w.de/poc/headless_protocol_handlers.py (custom mailto handler) Not working with "option.headless = True" - but after disabling this line, the redirect works. |
|||
►
Sign in to add a comment |
|||
Comment 1 by krajshree@chromium.org
, Dec 18 2017