Automatic website reconnection

CoHo Appz World Backup - Visual Studio 2022 patch

Updated October 4, 2026.

What the fog usually means

This website uses Blazor Interactive Server. A browser connection to the server supports its interactive controls. Blazor's default reconnect display can cover the page when that connection is interrupted. Network changes, a sleeping PC, a suspended browser tab, an expired page session, or an IIS process restart can lead to this display. The symptom alone does not identify which event occurred on your hosting account.

The original home page also called JavaScript formatting/focus helpers after rendering without guarding against a disconnected circuit. Those calls can fail during a network interruption. The patch handles the expected disconnection/cancellation errors so they do not make these rendering helpers fatal.

Changed behavior

• A small connection banner replaces the default reconnect fog. The workspace stays visible and readable. Its controls temporarily become unavailable while disconnected.
• The browser first tries to resume the existing page session. When that succeeds, the banner goes away and the current page state remains.
• An offline browser waits for connectivity. A hidden tab waits until the user returns; the online, focus, and visibility events wake a pending retry.
• If the server rejects the old page session, or 12 reconnect attempts fail, the browser checks /health before refreshing. It avoids automatically navigating to an error page while the website is down.
• The automatic refresh is limited across reloads in the same tab until the page has remained connected for 60 seconds. This prevents rapid refresh loops. If browser session storage is unavailable, automatic refresh is disabled and the Reload page button remains available.
• Retry now wakes the existing recovery loop. Reload page works independently of Blazor, so it remains usable while the page session is disconnected.
• Browser and server timeout settings are 60 seconds, with 15-second keep-alive intervals. The server retains disconnected page sessions for up to 10 minutes, subject to its existing retained-circuit limit and available resources.
• Expected JavaScript disconnection/cancellation errors in the home page's rendering helpers are handled. Other application failures can still appear in the page-error bar.

The recovery script never submits or repeats a backup, restore, delete, cleanup, or settings command. A local companion job already in progress can continue while the browser reconnects. An automatic full-page refresh may reset unsubmitted text or an open confirmation dialog; check your entries before submitting a new command.

The existing tab-scoped browser pairing information is reused after refresh when its server-side relay session remains valid. If the server process has restarted, its in-memory relay is gone: disconnect the companion after any current job finishes, generate a new code, and pair again. This patch does not persist device sessions across server restarts or prevent hosting-pool recycling.

Apply and publish

1. Close Visual Studio 2022. Extract CoHo-Appz-World-Backup-Reconnect-Patch.zip to a separate folder.
2. Double-click Apply-Patch.cmd and enter the full path to your existing solution folder. It must contain src/Mcs.Web/Mcs.Web.csproj.
3. The apply script stages all edits before writing. It merges known code fragments, appends the connection-banner styles, and adds the recovery script, this guide, and optional JavaScript tests. If an expected fragment was customized and cannot be matched, it stops before writing; review the included unified diff and merge that edit in Visual Studio.
4. Existing changed files are backed up to a timestamped CoHo-Appz-World-Backup-Reconnect-Backups folder beside the solution folder. Your project frameworks, publishing profiles, publisher settings, and companion code are not replaced.
5. Reopen Visual Studio and build Release. Publish Mcs.Web to a local folder, then inspect the output before uploading.
6. Verify wwwroot/mcs-reconnect.js and the updated CSS are present. The generated web.config must keep hostingModel="outofprocess" on <aspNetCore> and normal stdoutLogEnabled="false". The separate IIS patch remains applicable if your earlier source has not received it.
7. Before uploading, ensure the publisher contact values used by your currently working website are also configured in your publish output. A direct Visual Studio publish uses your local src/Mcs.Web/appsettings.json; copy the real contact configuration there if you previously set it only on the server. Keep the actual companion ZIP in App_Data/Downloads, especially when a profile removes additional destination files.
8. Publish/upload the web output and refresh the browser once with Ctrl+F5. The companion does not need to be republished for this change.

Applying the source patch does not deploy to the host or restart the application pool. Preserve the working hosting configuration. The source archive includes the earlier out-of-process project setting; this reconnect patch does not change your local target framework.

Verify on your website

Use a test world when testing command behavior.

1. Pair the companion and leave the page open beyond the time when the fog previously appeared. The page should either remain connected or display the small recovery banner.
2. With no job in progress, switch the browser offline using Developer Tools, wait for the connection loss to be detected (up to approximately the configured timeout), and switch online again. The banner should disappear after reconnection, or the page should refresh once if the server no longer has its page session.
3. Minimize the browser or sleep/wake the PC, then return. Reconnection should resume automatically. An indefinitely suspended page cannot keep a server-side session alive forever.
4. While disconnected, confirm the workspace buttons cannot submit operations. The banner's Retry now and Reload page buttons should remain usable.
5. If testing a pool restart, do it when no job is pending and when you can interrupt every site sharing that pool. Expect a page refresh and a new companion pairing afterward; a restart discards the in-memory relay.
6. If an application error or repeated disconnection remains, capture the browser console message and the matching server/pool event. The patch improves recovery, but a recurring hosting failure still needs its cause investigated.

Automated checks

The included JavaScript tests use Node's built-in test runner with no external packages:

node --test .\tests\browser\reconnect.test.cjs

They exercise interruption recovery, offline/hidden tabs, server rejection, healthy-server gating, refresh-loop protection, duplicate/cancelled retries, blocked storage, manual retry/reload, initial startup failure, and timeout configuration.

The creation environment executed the JavaScript tests and syntax checks. XML/project references, source differences, patch payloads, and ZIP integrity were checked. It has no .NET SDK, PowerShell, or Windows desktop; the C# build, Windows apply script, and live IIS behavior must be verified on your PC/host. Passing the mocked JavaScript scenarios is not a substitute for the live checks above.

Undo

Close Visual Studio. Copy changed files from the printed backup folder over their matching relative paths in your solution. Newly added files that did not have originals are listed in the backup folder's ADDED-FILES.txt; remove only those new files when reverting. Rebuild and republish the reverted web project. Keep the backup folder private.

References

• Microsoft: Blazor SignalR guidance: circuit timeout settings, custom reconnection handlers, and the reconnect/reload distinction.
• Microsoft: Blazor JavaScript interoperability: JavaScript calls after a disconnected circuit and handling JSDisconnectedException.
• SmarterASP.NET: Recycle an application pool.