Fix link click interception in shadow roots

[SteveSandersonMS]

This is a fix for #27070, which we should consider for a patch.

Description

HTML <a> elements within shadow roots are invisible to the link click interception code. So when an end user clicks on a link that's inside the shadow root of a custom element, it triggers a full page load instead of a client-side navigation.

Customer Impact

Reported by a customer at #27070. There's no reasonable workaround (besides not using custom elements and shadow DOM).

The impact is that if you're using a library of custom HTML elements, which typically use ShadowDOM to render, then if you use them to produce any links, then those links will seem broken to the end user (as in, they trigger a full-page reload, destroying any app state in WebAssembly memory or discarding the Blazor Server circuit).

Regression?

No, this has always been the case. However, the use of custom elements and ShadowDOM is a growing area, especially as we try to guide customers to use custom elements like the FAST components.

The fact that this use case is growing in importance makes it relevant to consider patching rather than waiting a full year for 6.0.

We don't have to ship this in 5.0.1, but we should be prepared to ship it in a patch reasonably soon.

Risk

This changes the logic for processing clicks on all links, not just the ones in shadow roots. Although I'm not aware of any cases where the new logic might fail, and all our E2E tests pass, maybe I missed some case. It's unfortunate we don't have any opportunity to put this in front of customers any any preview form.

One possible mitigation would be putting this in master right away, and waiting until 5.0.2 (or later) to ship it as a patch, just in case anybody discovers problems in a 6.0 preview.

[SteveSandersonMS]

AFAIK there aren't any supported browsers that don't support Event.composedPath.

The only reason I'm keeping the older logic as fallback is in case someone has somehow polyfilled enough to make Blazor Server 5.0 run on IE11/legacy-Edge, in which case we don't want this patch to create the need to add yet another polyfill. I doubt anyone is in that situation, but this is being super-cautious because patch.

[ghost]

Hello human! Please make sure you've included the Shiproom Template in a comment or (preferably) the PR description. Also, make sure this PR is not marked as a draft and is ready-to-merge.

[captainsafia]

LGTM!

[mkArtakMSFT]

@SteveSandersonMS let me know if you want me to merge this (in case you don't have permissions to do so).

[SteveSandersonMS]

@mkArtakMSFT Would it work OK if we chose not to merge this for 5.0.1, but instead hold it back until a later patch?

Update: we discussed and decided it's better to merge now.