

This would involve not just extracting a url param, but also checking that other params are only those that we confidently understand.
BUGZILLA LOGS WINDOWS
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. 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. These are the reasons why I've held off on implementing it so far. (We may be able to avoid that prompt by setting a value in HKSU\Software\Microsoft\Windows\CurrentVersion\ApplicationAssociationToasts when registering.) I do use Edge Deflector myself, but I'm confident in my ability to debug issues. I don't think we should put this choice in front of all users, expecting them to make an educated decision.

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. microsoft-edge:?launchContext1= (used like launchContext1=_cw5n1h2txyewy, maybe only for telemetry?).has ?taskbarPin&url= next to microsoft-edge: (not sure what difference this makes).has the string microsoft-edge:about:compass?correlationId=%s (seems meaningless?).
BUGZILLA LOGS WINDOWS 10
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: This could be very hard for a user to deal with when they're trying to get Windows support. 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). There are several internal Windows support links that use microsoft-edge:, and we can expect there will be more. Thanks for implementing this! I'm not sure we should ship this feature, though.
