Skip to main content

Client - Background Tabs

Browsers put inactive background tabs to sleep to save CPU, memory, and battery. A sleeping tab is frozen and executes no JavaScript, so the ADITO Web Client stops sending its heartbeat to the server. Depending on how long that lasts, users either continue seamlessly, wait a few seconds while the interface is rebuilt, or find the login page when they switch back.

This is a side effect of the browser's power-saving behavior rather than an application error. This page covers how to recognize the pattern and how to prevent it. For the timeouts involved and their configuration, see Client Sessions and Timeouts.

What Users Experience​

Everything follows from the heartbeat going silent the moment the tab is frozen. From then on, three stages can be reached:

  1. The tab is only considered dead, nothing else. After a short while without a heartbeat, the server marks that tab as gone but does not necessarily clean it up. If the session has no other tab open, the user notices nothing at all on returning.
  2. The interface is rebuilt. If another tab of the same session is active, its calls trigger the cleanup and the sleeping tab loses its server-side interface. On returning, that tab rebuilds itself, which takes a few seconds and feels like a short freeze. The session and all open data are preserved, and the user stays signed in.
  3. The user is signed out. Once the connection timeout has elapsed, the whole session ends. This is a real logout, and unsaved input is lost. The user lands on the login page with a notice about the timeout.

A tab that the browser discarded completely rather than only froze is not a problem in itself. It reloads on return and finds the same session again, as long as the session has not timed out in the meantime.

note

An open WebSocket connection does not keep the session alive, because only real HTTP calls do, and while the client is idle the heartbeat is the only one that still arrives. The push connection also does not prevent a tab from being put to sleep.

Why the Same Setup Feels Different for Each User​

What matters is not how long the tab sleeps, but that the clock starts running the moment it falls asleep. The session ends roughly half an hour after that point, regardless of how long the browser waited before putting the tab to sleep.

That waiting period differs considerably. In Microsoft Edge it is two hours with the default policy setting, 30 minutes in battery saver mode, and 5 minutes in efficiency mode. Users on the same system therefore run into the timeout after very different idle times, which makes the behavior look inconsistent even though the server side is identical for everyone.

Microsoft Edge also keeps some tabs awake on its own, for example tabs that play audio, capture screen or media, hold a Web Lock, or are being inspected by DevTools. Sites that Windows treats as intranet are exempt as well, which is why the same application can behave differently depending on the URL it is opened with. That classification comes from the Windows Local intranet security zone, which Microsoft Edge inherits from the operating system. Besides the sites an administrator assigns to the zone, Microsoft Edge also puts sites there by heuristics, which include dotless host names such as https://payroll and sites that the proxy configuration script excludes from the proxy. Microsoft does not document the exemption in more detail than that, so treat it as a possible explanation for inconsistent reports rather than as a guarantee. The reliable way to keep a tab awake is the explicit exception described below.

note

Background-tab suspension is not specific to a single browser. In practice the effect is currently observed with Microsoft Edge, whose sleeping tabs feature is enabled by default, while Google Chrome and Safari throttle background tabs less visibly. No browser guarantees that a background tab stays fully active, so switching browsers is not a reliable remedy.

Recognizing the Pattern​

Tab suspension is the cause if all of the following apply:

  • The delay or the logout occurs only after returning to a tab that was in the background for a while.
  • The same views and actions respond normally while the tab stays in the foreground.
  • Other users working in the same system at the same time are not affected.
  • The server log shows no long-running database queries or JDito processes for that moment.
tip

Two signals confirm it quickly. Microsoft Edge shows a tab that has been put to sleep faded in the tab bar, similar to a disabled element. On the server side, a session that ended this way is logged as CONNECTION_TIMEOUT, whereas USER_TIMEOUT means the user inactivity timeout ended it instead.

If the delay also occurs during continuous work in the foreground, treat it as a regular performance issue and continue with Analyze Performance.

Keeping the Application Tab Active​

Excluding the application from tab suspension is the direct remedy: the tab is never frozen, the heartbeat keeps running, and no connection timeout can elapse.

Per User in the Browser Settings​

Microsoft Edge offers an exception list in its performance settings:

  1. Open edge://settings/system, or select Settings and more > Settings > System and performance.
  2. Open the Performance section.
  3. Under Always keep these sites active, select Add site.
  4. Enter the full URL of the ADITO application and confirm with Add.

The change takes effect immediately. Google Chrome provides a comparable list under Settings > Performance.

Centrally by Browser Policy​

On managed devices, distribute the exception by policy so that users do not have to configure anything themselves. For Microsoft Edge, the relevant policies are:

PolicyPurpose
SleepingTabsBlockedForUrlsDefines a list of URL patterns that must not be put to sleep. Sites on this list are also excluded from efficiency mode and tab discarding.
SleepingTabsEnabledControls whether sleeping tabs are used at all. Check this policy as well, because a central setting overrides the user's own choice.
SleepingTabsTimeoutDefines the inactivity timeout after which a background tab is put to sleep.

Add the application to SleepingTabsBlockedForUrls using the same URL pattern format as other Microsoft Edge URL list policies, for example:

https://adito.example.com
[*.]example.com

These policies are available in Microsoft Edge 88 and later on Windows and macOS. They are managed either by group policy under Administrative Templates > Microsoft Edge > Sleeping tabs settings, or by the corresponding registry values and macOS preference keys.

info

If SleepingTabsEnabled is disabled centrally, the list in SleepingTabsBlockedForUrls is not evaluated, because no site is put to sleep automatically in that case.

Google Chrome provides equivalent policies: TabDiscardingExceptions for the URL patterns that must never be discarded, and HighEfficiencyModeEnabled for the Memory Saver mode itself. Configure them alongside the Edge policies if both browsers are in use.

Where Browser Settings Are Not an Option​

If the browser cannot be configured, the deadlines can be raised on the server instead, so that a sleeping tab no longer exceeds them. This affects all clients and delays the detection of clients that actually crashed, so weigh it against the browser-side exemption first. See Configuring Longer Deadlines.

Sources on tab suspension and throttling