SignalR connections start slower and slower in Firefox in VS 2022 (up to 60 seconds)

Update by @SteveSandersonMS Since I’ve tracked this down to be something that happens in all SignalR apps, not just Blazor Server, I’ve changed the label to area-signalr so the relevant people can take a look. Lots of this discussion is about Blazor Server, but don’t be distracted into thinking it’s specific to that!

---

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

Blazor Server is said to handle thousands or tens of thousands of users. With this behavior, best I can do is between 5 and 20 in Firefox (all subsequent circuits take 30 or 60 seconds to load).

This issue is best visible when using render-mode="Server" because with this setting, the page is blank white before the circuit is opened (with ServerPrerendered, the page is shown instantly and is responsive for html links but irresponsive for actual Blazor content).

When opening multiple tabs in Firefox (latest - 97.0.1 (64-bit)), circuits take longer and longer to instantiate - 1,1,2,3,5,10,20,30,60, … seconds with more and more tabs created. This does not happen in Microsoft Edge or Chrome.

This behavior is not affected by Firefox add-ons. I have disabled them all and the bug persists.

Note: there is no significiant CPU usage when I am waiting for the page load in Firefox. Also, opening circuits in MS Edge while waiting 60 seconds for a circuit in Firefox can be done without any issue. They will still open instantly.

This bug is present in the default .NET 6 Blazor Server application template and also in the .NET Core 3.1 Blazor Server application template. I haven’t tested .NET 5 or any other.

This can be seen more clearly when overriding the default CircuitHandler which captures the lifetime of circuits. I have created a sample application and a sample video to show this with printing into Console.

Expected Behavior

Circuits are created instantly in Firefox, too.

Steps To Reproduce

Create .NET 6 or .NET 3.1 Blazor Server app from template. Switch to render-mode Server for clearer evidence. Run the application in Firefox (I used latest - 97.0.1 (64-bit)) and open new tabs. They will take longer and longer to load - 1,1,2,3,5,10,20,30,60, … seconds with more and more tabs created.

Exceptions (if any)

No response

.NET Version

6.0.200

Anything else?

VS 2022 Preview (latest) and also non-preview (latest). Blazor Server circuits in Firefox bug.zip

https://user-images.githubusercontent.com/64279914/156048565-0399f456-4e5e-41d4-b1f5-64d27d9ab23d.mp4

Video: skip to 1:40 to watch the behavior in Firefox.

[SteveSandersonMS]

I’ve investigated, and I think this is most likely a longstanding problem inside Firefox. Specifically, this issue which was closed as “by design” because of this implementation.

More broadly this is an issue that occurs with any SignalR app, not just Blazor Server. @halter73 @BrennanConroy - pinging you in case you have any insights. I created a SignalR-only (no Blazor) repro at https://github.com/SteveSandersonMS/SignalRFirefoxRepro. The behavior you get when opening lots of tabs in Firefox is like this:

I can only repro this issue when VS’s “Auto build and refresh option” is set to “Refresh after build” or “Auto refresh after saving changes”. Those are the two options that cause VS to inject the aspnetcore-browser-refresh.js script. This might be required to repro the issue because aspnetcore-browser-refresh.js also sets up a second websocket connection (not via SignalR), and at least one independent person reported this kind of phenomenon when they had two websocket connections on each page load.

Using Wireshark during these long delays, it does appear that Firefox isn’t sending any outbound packets, so it doesn’t seem to be even trying to start a WebSocket connection. That would be consistent with the “by design” behavior mentioned in Bugzilla, since it deliberately pauses the outbound connection. It’s also consistent that the delay roughly doubles each time, which is also part of this design.

So:

@halter73 @BrennanConroy If you have any suspicions on what we might be doing wrong to trigger this, please let us know! If this problem can only occur in development then it might not be so bad, but if it could occur in prod - especially if it’s actually a server-side issue that could span users - then of course it would be a much bigger deal.

@janseris If this is a Firefox defect, your best bet is probably to follow up with Firefox. I’m not sure there’s anything we could do about it in this repo.

[abdollahkahne]

I test a Blazor Server App on my Firefox (97.0 64 bit) on Ubuntu both Server and ServerPrerendered mode and It works smoothly for up to 100 instance as I tried. I am using vs code and C# for Visual Studio Code (powered by OmniSharp) extension for development.

1:08:07 AM
XH520iCOkUeikaVYL7fqS0keHI-PlTgowXFXmRY1yUM
Number of Connected Cirecuits After Connect: 96
1:08:07 AM
NRnhMMerUE5GXmkiLANvRnEvVwnsNh3qn6z4rsK-x0Y
Number of Connected Cirecuits After Connect: 97
1:08:07 AM
MdtWA0v5RDmqx8mjkwCRrETkDJ7axAji6VJmqdnZ0Rk
Number of Connected Cirecuits After Connect: 98
1:08:07 AM
1f3idRL_Qfhr_nq5t755qjSzux1UTY6DEHfXUzx5sho
Number of Connected Cirecuits After Connect: 99

and I used a modified copy of this sample: Blazor Server with SignalR sample of microsoft docs

which is located here My custom Repo