Heartbeats stop working if I leave the app

[shipswake]

I have two forms communicating via FDC3. Everything works correctly when I pass an intent from form 1 to form 2. Form 2 responds to the intent as expected.
If I leave the browser alone for some time when I send an intent from form 1 form 2 does not respond but a new instance of form 2 is opened.
Form 2 is considered not responding to heartbeats and form 2 is eventually terminated.

Has anyone run into this before?
Any direction is appreciated

[kriswest]

The heartbeats exist to catch cases where an app is unable to message the DA before its window is closed (or because the render thread crashed). However, I suspect that the browser maybe throttling the window or putting it to sleep when not focused, causing it to not respond to the heartbeat and the DA deciding its dead. This may benefit from some refinement, for example setting better timeouts or something more complex involving handling browser events from the PageLifeCycle API...

If you're working with the toolbox/fdc3-for-web/fdc3-web-impl package the relevant code is at:

FDC3/toolbox/fdc3-for-web/fdc3-web-impl/src/handlers/HeartbeatHandler.ts

Lines 41 to 83 in 9ad3c50

	constructor(pingInterval: number = 1000, disconnectedAfter: number = 5000, deadAfter: number = 20000) {
	this.timerFunction = setInterval(() => {
	this.contexts.forEach(async sc => {
	const apps = await sc.getAllApps();
	apps
	.filter(app => app.state == State.Connected || app.state == State.NotResponding)
	.forEach(app => {
	const now = new Date().getTime();
	this.sendHeartbeat(sc, app);
	// check when the last heartbeat happened
	const lastHeartbeat = this.lastHeartbeats.get(app.instanceId);
	const currentState = app.state;
	if (lastHeartbeat != undefined) {
	const timeSinceLastHeartbeat = now - lastHeartbeat;
	if (timeSinceLastHeartbeat < disconnectedAfter && currentState != State.Connected) {
	console.error(
	`Heartbeat from ${app.instanceId} for ${timeSinceLastHeartbeat}ms. App is considered connected.`
	);
	sc.setAppState(app.instanceId, State.Connected);
	} else if (timeSinceLastHeartbeat > disconnectedAfter && currentState == State.Connected) {
	console.error(
	`No heartbeat from ${app.instanceId} for ${timeSinceLastHeartbeat}ms. App is considered not responding.`
	);
	sc.setAppState(app.instanceId, State.NotResponding);
	} else if (timeSinceLastHeartbeat > deadAfter && currentState == State.NotResponding) {
	console.error(
	`No heartbeat from ${app.instanceId} for ${timeSinceLastHeartbeat}ms. App is considered terminated.`
	);
	sc.setAppState(app.instanceId, State.Terminated);
	} else {
	// no action
	}
	} else {
	// start the clock
	this.lastHeartbeats.set(app.instanceId, now);
	}
	});
	});
	}, pingInterval);
	}

It has baked in constants (which could be configurable. You should also console messages that you can look for in the DesktopAgent window's console that should identify when it thinks a window has died/stopped responding. You could also add some of the example code from the PageLifeCycle API docs to report when the page changes state and see how timing lines up: https://developer.chrome.com/docs/web-platform/page-lifecycle-api#how_to_observe_state_changes (i'd probably log the timestamp with the events as you'll need to compare across two different window consoles: DA & app).

I'd be very interested in what you learn, as would @robmoffat and @SeeWhatsOn I imagine.

[shipswake]

What is the thinking with disabling the heartbeats?
FDC3 will ignore the terminated app and send the intent anyway?

[kriswest]

Also, its up to the Desktop Agent what it does based on the heartbeat signals (if/when enabled). In the reference implementation demo that's controlled in the HeartbeatHandler (hence we should be correcting the argument handling in DefaultFDC3Server to let you control that as described above and in #1678).

[kriswest]

What is the thinking with disabling the heartbeats? FDC3 will ignore the terminated app and send the intent anyway?

Essentially, yes. Doing a little research with AI and the various docs sites and there's a difference between the 'hidden' and 'frozen' states that's quite important. It may mean that we need to extend default heartbeats or add some handling for lifecycle states and conditionally extend them.

Have a read and let me know what you think - and whether you find out anything through your testing (with heartbeats off):

Can a web page execute any scripts or timers when in the 'hidden' life cycle state in chrome? If so, are there modifications we could make to allow an app to respond to messages or avoid the hidden state?

Short answer

• Yes — while a Chrome page is in the "hidden" state it can still execute JavaScript, but execution is throttled and many APIs (requestAnimationFrame, frequent timers) are suspended or clamped. The later "frozen" state (introduced by the Page Lifecycle API) can stop script execution entirely for that page. In practice you cannot rely on timely responses from a hidden tab, and you should treat hidden as an unreliable background state.

What actually happens in Chrome

• hidden (document.visibilityState === "hidden"): the page remains alive but the browser aggressively throttles work:
  • requestAnimationFrame is stopped.
  • setTimeout/setInterval callbacks are clamped / budgeted (longer minimum intervals, lower frequency).
  • Background tasks are budget-limited (timer budget model) so periodic callbacks may be delayed by seconds or more.
  • Network activity may still function, but delivery/processing of events can be delayed or deprioritised.
• frozen: the page’s renderer is suspended; JavaScript does not run at all until resume. Frozen is more severe than hidden and is used when the browser wants to conserve resources aggressively.
• discarded: the page can be unloaded entirely (no execution) and may be reloaded when reactivated.

Implications for heartbeat/message handling

• You cannot assume a quick heartbeat reply while a page is hidden. Heartbeat intervals of e.g. 1s will produce false failures.
• If a page is frozen, it will not respond at all until resumed.
• Service workers or background workers are not a general substitute for keeping UI pages responsive: service workers have different lifecycles and limited execution windows, and do not have access to the page DOM. Shared/dedicated workers will also be throttled or suspended.
• Hacks that historically kept tabs active (silent audio playback, continuous WebRTC streams, busy loops) are fragile, often break autoplay/power-management policies and are not recommended for production.

Practical modifications / recommendations

1. App-side: detect lifecycle and inform the Desktop Agent

   • Use visibilitychange, and (where available) freeze/resume events. Forward a lifecycleUpdate to the DA/WCP when state changes (active, hidden, frozen, resumed). This lets the DA make informed decisions instead of assuming crash.
   • Always persist essential state when you receive a hidden/freeze event (Chrome guidance: treat hidden as likely end of session).

2. DA/server-side: treat hidden/frozen specially

   • Do not treat missed heartbeats during a reported hidden/frozen period as an immediate crash. Introduce a Suspended state or extend the disconnected/dead thresholds while an app reports hidden/frozen.
   • Re-validate on resume: when the app reports resumed/visible, re-check connectivity and re-establish instance identity if possible.
   • Make heartbeat parameters configurable (pingInterval, disconnectedAfter, deadAfter) so implementors can tune for their environment.

3. Protocol/standard changes

   • Add a lifecycleUpdate (or similar) message to the Web Connection Protocol (WCP) so apps can forward lifecycle events to the DA reliably.
   • Specify DA behaviour for lifecycle events (how long to extend thresholds, Suspended semantics, reconnection rules).

4. Don’t rely on keeping the page artificially active

   • Avoid recommending hacks (silent audio, busy work) to keep pages from becoming hidden/frozen; they are brittle and may violate platform/power policies.

Suggested minimal app-side code pattern

• Detect and forward lifecycle changes. Replace sendLifecycleUpdate(...) with the actual mechanism your app uses to reach the DA (WCP client, postMessage, DesktopAgentProxy API, etc.):

function sendLifecycleUpdate(payload) {
// TODO: implement WCP / DA send. Example placeholder:
// wcpClient.send('lifecycleUpdate', payload);
console.log('Send lifecycle update', payload);
}

function notifyLifecycle(status) {
sendLifecycleUpdate({ status, timestamp: Date.now(), instanceId: window.__FDC3_INSTANCE_ID });
}

document.addEventListener('visibilitychange', () => {
notifyLifecycle(document.visibilityState === 'visible' ? 'active' : 'hidden');
});

// Some browsers support freeze/resume events
window.addEventListener('freeze', () => notifyLifecycle('frozen'));
window.addEventListener('resume', () => notifyLifecycle('resumed'));

// Fallbacks
window.addEventListener('pagehide', () => notifyLifecycle('hidden'));
window.addEventListener('pageshow', () => notifyLifecycle('active'));

Cross‑browser caveat

• Support and exact timing vary by browser and version. Chrome exposes freeze/resume; Edge/other browsers may behave differently. Tests must be run across the browsers you intend to support and behaviour documented.

Recommended next steps for FDC3

• Prototype forwarding lifecycle events from app to DA (WCP lifecycleUpdate message).
• Modify HeartbeatHandler/DA to honour lifecycle state (introduce Suspended state, make thresholds configurable).
• Test across Chrome, Edge and other targets to determine sensible default timeouts and acceptance criteria.
• Document recommended patterns for implementors (persist state on hidden, forward lifecycle, tune timeouts).

If you want, I can:

• Suggest a concrete lifecycleUpdate message schema for WCP.
• Draft a small PR patch for the toolbox implementation (app-side listeners + forwarding stub) you can use to test.

We should raise an issue if changes are needed!

Also, it may help your testing to visit edge://discards/ and chrome://discards/ as you can see the state of each page (is it hidden?) and can force freeze or discard them.

[shipswake]

It seems to work fine with heartbeats turned off. I'll have to remember why we needed the heartbeats!

[kriswest]

If a render thread crashes or is closed from outside the browser you don't get a disconnection message back in the agent so you don't know it's gone. It's possible we're creating a bigger problem than we're solving because of lack of consideration for the page lifecycle in the solution?

As you're testing with heartbeat switched off, you could try using chrome://discards or killing the render thread via task manager (chrome or windows, get PID from chrome taskmanager) and check if you get zombie instances that don't exist in the intent resolver

[shipswake]

Interesting Edge and Chrome function differently. Edge on the left considers the app connected. Chrome on the right considers the app terminated.

[kriswest]

Is that timing related? or the level of the thottling? Both went to 'Not responding', but then edge responded to a heartbeat and went back to connected...

I've done a quick bit of (AI assisted) research into differences between their 'intensive throttling' behaviour (introduced in chrome 87-ish) on hidden tabs - they both use the same timeouts, but it seems that chrome uses some additional heuristics to decide if the app should be throttled, while edge has a 'sleeping' tab feature that ends execution completely at 2 hours idle. I suspect chrome was more sure your app was idle??

🔄 Chrome (Post v87 to v117+)

✅ Confirmed Changes and Enhancements

Background Timer Throttling (Still Active)

1. The 1-minute wake-up limit for background tabs after 5 minutes remains in place.

   • This is part of Chromium’s Intensive Wake Up Throttling policy.
   • Heuristics-Based Throttling

2. Chrome now uses additional heuristics to decide when to throttle:

   • Tabs with no audio/video playback
     • Tabs not interacting with the user
     • Tabs not using WebRTC or WebSockets actively
     • Foreground Tab Optimization

3. Chrome prioritizes foreground tab performance by reducing CPU time for background tabs even more aggressively.

   • Battery Saver Mode (Chrome 108+)

4. Introduced a Battery Saver mode that further reduces background activity:

   • Limits frame rates
   • Reduces timer frequency
   • May delay non-critical tasks
   • Page Visibility API Integration

Chrome uses the Page Visibility API to determine when to throttle or pause execution.
Developers can use document.visibilityState to detect and adapt.

🟦 Microsoft Edge (Post v88 to v117+)

✅ Confirmed Changes and Additions

1. Sleeping Tabs (Introduced in Edge 88)
   • Tabs go to sleep after 2 hours of inactivity (configurable).
   • Sleeping tabs pause all JavaScript execution, not just throttle timers.
   • Edge uses heuristics to exclude important tabs (e.g., playing media, pinned tabs).
   • Enhanced Sleeping Tabs (Edge 104+)
2. Improved detection of resource-heavy tabs.
   • Tabs can be put to sleep sooner if they consume excessive CPU or memory.
3. Efficiency Mode (Edge 96+)
   • When enabled, it:
     • Forces sleeping tabs more aggressively
     • Reduces background timer frequency
     • Limits animations and transitions
4. Group Policy and Enterprise Controls
   • Edge allows IT admins to configure throttling and sleeping behavior via Group Policy.

⏱️ Timeouts and Execution Summary (2025)

Feature	Chrome (v117+)	Edge (v117+)
Initial Throttling	Immediate in background	Immediate in background
Aggressive Throttling	After 5 minutes	After 5 minutes
Wake-up Frequency	1 per minute	1 per minute
Sleeping Tabs	❌ Not native	✅ Pauses JS entirely
Battery Saver Impact	✅ Reduces timers	✅ May force tab sleep
Efficiency Mode	❌ Not available	✅ Reduces background activity
Enterprise Controls	Limited	Extensive via Group Policy