[Blazor] Disconnect alternative proposal

[javiercn]

Based on #39370

We currently do this within the unload event because that's when we know the page is going to be terminated. As @TanayParikh points out this event isn't raised in some scenarios (closing a tab, mobile user switches apps, etc.) and the circuit remains disconnected for the default reconnection grace period instead of being fully terminated.

We could potentially do better in this scenario by changing the approach into a "soft" disconnect. The way this works is as follows:

• When we detect an unload event, we register a handler that calls /disconnect(false) on the server.
• In that case, the server registers a timestamp of when this happened.
• If a disconnection happens within a grace period after the "disconnect" call happens (lets say 10 seconds) the server terminates the circuit right away instead of adding it to the disconnected registry.
• If the grace period has passed after the signal was sent, we assume that the original signal was dismissed and we put the circuit on the disconnected registry instead.

This gives us a bit more flexibility as normally, given the unload event is unreliable, we at least get to be notified in other cases. As @TanayParikh mentions, visibilitychange might be another option. (For example, if the visibility changes right before loosing the connection)

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 7 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[mkArtakMSFT]

@javiercn are you still interested in us pursuing this proposal?

[mkArtakMSFT]

I'm closing assuming the answer is "no". If you disagree, please reopen and move to the .NET 9 PLanning milestone.