Hello. We have a situation where a Windows protocol handler product is used to open documents from an EDRMS. At some point Adobe has apparently changed how it opens links. Now it simply passes a link to the system's default browser on the command line. As as some browsers (notably Chrome and recent builds of Edge which are based on Chromium) don't handle protocol handler URLs from the command line, this style of link now fails to activate.

Links will be of a form similar to example://12345/open but I think this is an issue for all Windows protocol handlers.

ENVIRONMENT:

Windows 10,
Adobe Acrobat Reader DC 2021.001.20145, and
Chrome 89.0.4389.90 (64 bit) as the system's default browser.

STEPS TO REPRODUCE:

(1) Create and register a Windows Protocol Handler. (Example instructions: https://medium.com/swlh/custom-protocol-handling-how-to-8ac41ff651eb )

(2) Make sure Chrome is the system's default browser.

(3) Create a PDF which includes a hyperlink to open a URL of the registered protocol's form.

(4) Confirm that the protocol handler activates and does its thing when pasted into the Windows Start/Run dialog. (This is just to confirm that it's registered properly as far as Windows is concerned.)

(5) Open Adobe Acrobat Reader DC, disable "Enable Protected Mode At Startup" under the Enhanced Security preferences, and restart Adobe Acrobat Reader DC.

(6) Open the PDF that was created in step 3.

(7) Click the protocol handler's link, and click through any warnings.

EXPECTED RESULT:

• The protocol handler should be run according to the link that was clicked. (In our own case, the designated executable should go to the EDRMS and cause the document to be checked out and opened.)

OBSERVED RESULT:

• A blank Chrome browser window opens.
• Interrogating the process list with Powershell indicates that the new Chrome window was opened with the protocol handler's URL on the command line. For example:

PS C:\WINDOWS\system32> Get-CimInstance win32process | Where-Object {$.Name -eq "chrome.exe"} | Select-Object CommandLine

CommandLine

"C:\Program Files\Google\Chrome\Application\chrome.exe" --single-argument example://12345/open
"C:\Program Files\Google\Chrome\Application\chrome.exe" --type=crashpad-handler "--user-data-dir=C:\Users\usernm\AppData\L...
"C:\Program Files\Google\Chrome\Application\chrome.exe" --type=gpu-process --field-trial-handle=1660,1197437607337992284,2...
"C:\Program Files\Google\Chrome\Application\chrome.exe" --type=utility --utility-sub-type=network.mojom.NetworkService --f...
"C:\Program Files\Google\Chrome\Application\chrome.exe" --type=utility --utility-sub-type=storage.mojom.StorageService --f...
"C:\Program Files\Google\Chrome\Application\chrome.exe" --type=renderer --field-trial-handle=1660,1197437607337992284,2916...
"C:\Program Files\Google\Chrome\Application\chrome.exe" --type=renderer --field-trial-handle=1660,1197437607337992284,2916...
"C:\Program Files\Google\Chrome\Application\chrome.exe" --type=renderer --field-trial-handle=1660,1197437607337992284,2916...

ADDITIONAL:

If Firefox or MSIE was set as the default browser, then the browser opens. It typically displays an additional warning, but still allows the protocol handler to be activated. This is consistent with those browsers' behaviour when a non-http link is provided on the command line.

Ideally, if there's no compelling reason not to, I think Adobe Reader should be telling the OS to handle the protocol handler links instead of the default browser. It might be that this will still fail when Adobe Reader is running in Protected Mode, but we're making a conscious decision to run it without protected mode in some contexts so that we can use these links.

Thanks.