Edge 133 breaks links for custom protocol handlers

Question

Edge 133 breaks links for custom protocol handlers

Eric G 10

The issue described in https://learn.microsoft.com/en-us/answers/questions/2110073/edge-130-breaks-file-url-links has arisen again in Edge 133 and the prior workarounds to use the "Experimentation and Configuration Service" GPO or launch Edge with --disable-features=StandardCompliantNonSpecialSchemeURLParsing no longer resolve the issue.

3 answers

Your answer

Answer 1

Anonymous

Hi @Eric G

This is the expected behavior. The workarounds are temporary. The feature is turned on again in Edge version 133. You can refer to the comment of open issues 130:

Note: This feature is turned on again in Microsoft Edge version 133.0.3065.10 and higher. Customers are encouraged to test the impact of this feature and prepare for the change in behavior.

To accommodate this change in behavior, software vendors that implement custom protocol handlers are urged to review developer guidance at Support Non-Special Scheme URL - Google Docs, with special focus on the "How to fix your custom URLs" section.

If the answer is the right solution, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Regards,

Yu Zhou

Eric G 10 Reputation points

2025-02-25T14:40:50.2333333+00:00

Thank you for the response and relevant detail. We tried unsuccessfully to resolve this issue using the information in the "How to fix your custom URLs" section of Support Non-Special Scheme URL - Google Docs when this issue first arose in Edge 130. I wonder if you can help us understand what is wrong with our custom protocol handler format.

Some examples of our custom protocol handler format are as follows:
intranetsite.vbscript://winword.exe
intranetsite.vbscript://shell:mycomputerfolder
intranetsite.vbscript://\\domain\path\backup settings.bat

In that testing, we tried things like changing intranetsite.vbscript to intranetsite-vbs to remove the period from the protocol handler, removing spaces from file names (e.g. backupsettings.bat) and trying various forms of multiple forward and backward slashes in the path (e.g. //domain/path/file.bat, \\\\domain\\path\\file.bat).

NOTE: There's a corresponding registry entry on all Windows devices that use this intranet site that then process these calls using a VBS file that is run at \\domain\path\RunParam.vbs" "%1". This has worked for us for many years in both MSEdge and Chrome before that, until the behavior change in v130-133.
Anonymous

2025-02-26T06:32:06.44+00:00

Hi @Eric G

You can use https://timothygu.me/urltester to test if your URLs are valid. They must meet the URL Standard.

I can provide some suggestions regarding your custom URLs. You could have a try. First, change intranetsite.vbscript to intranetsite-vbscript. For the first URL, it lacks hostname. For the second URL, mycomputerfolder should be a number as it's the <port> part. For the third URL, you could try to remove space and use slashes. For example:

intranetsite-vbscript://host/winword.exe

intranetsite-vbscript://shell:number

intranetsite-vbscript://domain/path/backupsettings.bat
Eric G 10 Reputation points

2025-02-26T14:34:04.9233333+00:00

Thanks so much for the suggestions. Very much appreciated! ~~Some follow-up questions:~~

On the first item (intranetsite-vbscript://host/winword.exe), what do you mean by a hostname in this context? All of these commands are using a vbscript to run code on on the local computer. So in this case, this command would be launching winword.exe on the user's computer.

~~Same basic question with the second item (intranetsite-vbscript://shell:number, and currently intranetsite.vbscript://shell:mycomputerfolder). This is launching File Explorer on the user's computer.~~

Thanks again for all your help!

Answer 2

Deleted

This answer has been deleted due to a violation of our Code of Conduct. The answer was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

Comments have been turned off. Learn more

Answer 3

RESOLUTION:

I was able to resolve the issue using your guidance. There was no need to remove the period in the handler name, nor the spaces from the subsequent arguments, but I did need to eliminate the double forward slashes (//) from the handler call for a new format of "intranetsite.vbscript:" followed by whatever argument we needed to call (e.g. intranetsite.vbscript:winword.exe, intranetsite.vbscript:\domain\path\file name.docx).

In addition, I also needed to revise the parsing of this handler within our custom RunParam.vbs script to account for the removal of the forward slashes.

Thanks so much for the assistance! It was invaluable in pointing me in the right direction.

Share via

Edge 133 breaks links for custom protocol handlers

3 answers

Your answer