Blazor WebAssembly: Link that opens page in new tab causes freeze in original page (in Edge browser)

I have noticed for as long as I’ve been using Blazor WebAssembly (on .NET 5) that a simple link such as:-

<a href="https://www.microsoft.com" target="_blank">Microsoft</a>

can cause the originating page to become unusable. This happens in Chrome and Edge, but not (yet) FireFox.

Today I tried to repro in a brand new Blazor WebAssembly project, and got instant success.

To reproduce I did this:-

• Use Visual Studio 2019 Pro 16.8.3 on Windows 10
• Create new Blazor WebAssembly project (hosted by ASP.NET Core)
• Edit the Server project properties and select .NET 5 (although 3.1 also has the failure)
• Edit the Index.razor page in the Client project
• Add <a href="https://www.microsoft.com" target="_blank">Microsoft</a> to the bottom of the Index page
• Run the app in Chrome or Edge
• Click on Microsoft (i.e. the link we added above)
• Observe that the Microsoft home page has loaded in a new tab (and that tab has the input focus and is the currently displayed tab)
• Click on the original tab to go back to the Blazor app
• Sometimes on doing this, the Blazor app is inoperable. The cursor can move around, but the cursor is stuck on the “hand pointer” and clicking on links and controls does nothing!

When the original page seizes up like this, you can unfreeze it by opening and closing the Dev Tools window (e.g. tap F12 twice).

Points to note:-

1. It only happens sometimes. It may take three or four goes before you witness the problem.
2. It only seems to happen in Chromium browsers.

[Bellarmine-Head]

@SteveSandersonMS - some 8 months on since first reporting this issue, I went back to the web app in question (I’m now working full time on my second major Blazor WebAssembly web app, which doesn’t open pages in new tabs) and tested out the issue quite heavily on both Chrome and Edge. To be clear: this is with VS 2019 running with debugging enabled (i.e. hit F5).

Before testing I updated the Microsoft.AspNetCore.Components.WebAssembly.* packages to 5.0.8

The result is that I couldn’t reproduce the issue! Which is good.

What I did find is that after opening 10 or so extra tabs (alongside the website’s original page), on closing the browser it could take VS 2019 Pro 16.10.4 some while to return to its normal, I’m-not-debugging-anymore state (10+ seconds). But that’s not a hardship.

So it looks like this issue might/possibly/probably have got fixed somewhere down the line, what with 8 months of updates to Chromium, the Blazor packages and VS itself.

I am happy for this issue to be closed if would like to.

[javiercn]

@Andrew-Webb thanks for contacting us.

We believe this is an existing issue that has to do with Blazor debugging. Our recommendation if you are impacted by this is to run without debugging enabled as much as possible.