[Blazor] Updated Blazor Server reconnect UI

[MackinnonBuck]

Updated Blazor Server reconnect UI

Improves the default Blazor Server reconnect experience according to common customer feedback.

Description

Makes the following improvements to the Blazor Server reconnect UI:

• Rather than waiting three seconds before attempting reconnection, then waiting an additional default of 20 seconds between successive attempts, the new default settings use a configurable exponential backoff strategy:
  • Retry as quickly as possible for the first 10 attempts
  • Retry every 5 seconds for the next 10 attempts
  • Retry every 30 seconds until reaching the user-configured max retry count
  • Note: Customers can configure their own retry interval calculation function to override the default behavior
• When the user navigates back to the disconnected app from another app or browser tab, a reconnect attempt is immediately made
• If the server can be reached, but reconnection fails because server disposed the circuit, a refresh occurs automatically
• The default reconnect UI shows the number of seconds until the next reconnect attempt instead of the number of attempts remaining
• The styling of the default reconnect UI has been modernized

Fixes #55721

Customer Impact

Customers of apps built using Blazor Server often complain about the reconnection experience, which has motivated Blazor developers to open issues like #32113 suggesting improvements to reduce the amount of time the customer spends looking at the reconnect UI. This PR addresses many of those common concerns by performing reconnection attempts more aggressively. Unless apps have overridden the default reconnection options, they will automatically get thew new reconnect behavior by upgrading to .NET 9. In addition, the default reconnect UI styling has been updated. Styling changes will not affect apps that have overridden the default reconnect UI.

Regression?

• Yes
• No

Risk

• High
• Medium
• Low

This change only affects the reconnection experience when using Blazor Server or Server interactivity in a Blazor Web App. We have existing automated tests verifying core reconnect functionality. It's possible that some customers may have been relying on the previous defaults, but they'll still be able to override the new defaults if desired.

Verification

• Manual (required)
• Automated

Packaging changes reviewed?

• Yes
• No
• N/A

[MackinnonBuck]

Here are some additional open questions after some internal discussion:

• Is exponential backoff really necessary?
  • How big of a problem would it be if, by default, we constantly attempted reconnects without any waiting period? For apps with a limited number of users, one would probably prefer the faster reconnection, even if it means the server gets bombarded with reconnection attempts. Larger apps that need better scalability could reconfigure this default behavior (or use Blazor WebAssembly).
• Rather than showing a full screen overlay, should we only disable parts of the UI that are interactive?
  • Would need to consider the feasibility of implementing this - how do we know what "disabled" should look like for arbitrary UI?
• Could we wait to show the overlay until the user performs an interaction that requires the circuit?
  • This would allow the user to continue viewing the site if they're not interacting with it
  • We could optionally show a less intrusive reconnection indicator (e.g., an icon in the corner of the page) before the user attempts this type of interaction

Other notes:

• We think it's best to always refresh the browser when reconnection fails due to the circuit being disposed.
  • The initial argument against this is that this might end up wiping browser state before the user gets a chance to save their work
  • However, that the reconnect overlay prevents the user from being able to save their work anyway.
  • Thought: Absent of a stateful reconnection mechanism, is there a benefit to having the customer refresh manually? That way they're in control of the action that clears page state. It could be frustrating if the website refreshed upon returning to a tab, only to erase all the fields you had populated.
    • Maybe this could be configurable? e.g., we expose a JS callback that lets you decide what to do when reconnection gets rejected by the server. You could have different behavior depending on the page. Perhaps the automatic refresh is on by default only when stateful reconnection is enabled.

[javiercn]

Rather than showing a full screen overlay, should we only disable parts of the UI that are interactive?
Would need to consider the feasibility of implementing this - how do we know what "disabled" should look like for arbitrary UI?

We could set a custom property so that people can style the elements appropriately with container style queries https://developer.chrome.com/docs/css-ui/style-queries

Support for this is on its way https://caniuse.com/css-container-queries-style and will likely be there when we ship. On our part, setting up a custom property does not tie us into anything and people will be able to leverage this feature once it arrives on stable versions.

[MackinnonBuck]

I acknowledge that calls to this are somewhat scattered across the implementation - unfortunately there are a lot of ways in which the circuit can fail to connect, and connection is handled different when connecting for the first time vs reconnecting after a disconnect. Ideally the code would be structured in a way where changes in circuit state were handled in a more centralized manner, that would fairly significantly increase the size of this PR.

[MackinnonBuck]

Also the current possible values are 'connecting', 'connected', and 'disconnected'. In the period between reconnect attempts, the status is 'disconnected'. Also, the status is 'connecting' when the circuit is performing its initial connection.

I think this behavior accurately reflects the true state of the circuit, but I wonder if it's more useful to make the status '' when connected (or as long as a disconnection has never happened), 'reconnecting' when the circuit is disconnected but the reconnect handler is running, and 'disconnected' after reconnection has failed. Thoughts on this?

[MackinnonBuck]

Actually, it's not super clear to me what the expected usage pattern would be for this new custom CSS property. It seems that it would primarily be useful when using container style queries, which not yet supported in all major browsers.

We could alternatively put an attribute on the <html> element like data-circuit-status and then developers could use an attribute selector to customize styles depending on what that attribute's value is.

I'm probably going to scope this out of the PR for now, and we can think about adding an attribute or custom CSS property at a later time.

[wtgodbe]

/backport to main

[github-actions]

Started backporting to main: https://github.com/dotnet/aspnetcore/actions/runs/9289346719