This is required to open Firefox from Windows Search, Widgets, Cortana, Mail app, and many other in-box Microsoft apps.

Some third-party apps already provide this feature:

• https://github.com/da2x/EdgeDeflector
• https://github.com/sylveon/SearchWithMyBrowser

Now Brave implemented the microsoft-edge: protocol.
https://www.ghacks.net/2021/09/29/brave-1-30-supports-microsoft-edges-protocol-on-windows-to-become-the-true-default-browser-on-windows-10-and-11/

Depends on D127125

Thanks for implementing this! I'm not sure we should ship this feature, though. Here are my arguments:

1. There are several internal Windows support links that use microsoft-edge:, and we can expect there will be more. These may never be tested in anything but Blink-based browsers, could potentially do weird things based on user-agent detection, and they might use nonstandard features for better OS integration (in the future if they don't already). This could be very hard for a user to deal with when they're trying to get Windows support.

2. Grepping through C:\Windows on Windows 10 I found evidence of a few weird functions of this protocol that we may not want to interrupt:

• twinui.pcshell.dll has the string microsoft-edge:about:compass?correlationId=%s (seems meaningless?)
• twinapi.appcore.dll has ?taskbarPin&url= next to microsoft-edge: (not sure what difference this makes)
• microsoft-edge:?launchContext1= (used like launchContext1=Microsoft.Windows.Cortana_cw5n1h2txyewy, maybe only for telemetry?)

This isn't meant to be exhaustive, microsoft-edge: appeared by itself in quite a few other files and who knows how it is being used there. My point is that microsoft-edge: is an undocumented protocol, it may have functions besides navigating to a web page. Using an undocumented feature is tricky enough, but you need to be very confident before implementing one. (Might help to fall back to Edge in case we get something unexpected?)

3. By registering for the protocol, Windows will prompt the user to choose a handler the next time it is used. I don't think we should put this choice in front of all users, expecting them to make an educated decision. I do use Edge Deflector myself, but I'm confident in my ability to debug issues. (We may be able to avoid that prompt by setting a value in HKSU\Software\Microsoft\Windows\CurrentVersion\ApplicationAssociationToasts when registering.)

These are the reasons why I've held off on implementing it so far. I'm happy to discuss further.

FYI: https://www.ctrl.blog/entry/anti-competitive-browser-edges.html

If we do decide to ship this, I recommend that there be a robust fallback to Edge for anything that we can't reliably parse. I'd much rather have pages start opening in Edge instead of doing nothing as has happened with Edge Deflector several times (1, 2, 3, 4), and which is likely to continue with increased Windows 11 integration.

This would involve not just extracting a url param, but also checking that other params are only those that we confidently understand. To avoid potential webcompat issues with some Edge-specific pages, we may also want to restrict to an list of allowed URLs reliably identifiable as Bing searches; these are likely to serve standard pages, and anyway covers 90% of the uses of this protocol.

This will be a little tricky without being able to use the default handler for the microsoft-edge protocol, but it should be possible to find and use Edge's registration. This fallback should likely be done by a small helper so Firefox itself doesn't have to start for something it can't handle, this might be e.g. bolted onto the default browser agent.

The known URL list only includes URLs from Cortana/Windows Search at the
moment.
I don't restrict allowed URLs because users can type any URLs into search box.

Microsoft locked down microsoft-edge: protocol :(
https://www.ctrl.blog/entry/microsoft-edge-protocol-competition.html

:emk: sorry for the long period of radio silence here. With Microsoft's lock down of the microsoft-edge: protocol, there was no rush from my perspective to get to this. But we might do this just for Windows 10, so I will start reviewing your patches and see where we get to. Thanks for your work months ago!

I think today cumulative patch will lock down microsoft-edge: protocol on Windows 10.

(In reply to Masatoshi Kimura [:emk] from comment #10)

I think today cumulative patch will lock down microsoft-edge: protocol on Windows 10.

Mmm, interesting. I wonder? I will try to test this myself. Thanks so much, :emk!

https://github.com/da2x/EdgeDeflector/issues/158

I also verified that myself. Third-party apps can no longer take over microsoft-edge: protocol on Windows 10 with KB5008212 installed :(

(In reply to Masatoshi Kimura [:emk] from comment #12)

https://github.com/da2x/EdgeDeflector/issues/158

I also verified that myself. Third-party apps can no longer take over microsoft-edge: protocol on Windows 10 with KB5008212 installed :(

Masatoshi-san, that is disappointing. I will run this up my reporting chain but sadly we'll probably choose to not land the patches and close this as WONTFIX. A thousand thanks for all the work you've put into this: it's truly appreciated.

I do not suggest you implement "microsoft-edge:" protocol.
https://www.xda-developers.com/microsoft-edge-redirect-windows-11/