Register a window 'online' listener that retries every failed loader
when connectivity is restored — the trigger half of the failed-load
recovery story (SceneLoader.retryAllFailedLoaders is the engine; its
own doc names "after connectivity is restored" as the intended use).
Behavior:
No failures recorded → silent no-op (the common case).
An online transition with failures → toast that a retry is starting,
run retryAllFailedLoaders() (the loader serializes it against the
update lock internally), and toast the genuine outcome.
Background rounds stay silent while everything still fails; they toast
only when at least one load recovers.
Deferred results re-attempt. The lock is very plausibly held at
the moment online fires (the reconnect typically happens while an
update or LOD refinement is mid-flight — the very situation that
produced the failures), and online will not fire again while the
browser stays online. A deferred batch therefore re-attempts every
DEFERRED_RETRY_DELAY_MS up to MAX_DEFERRED_RETRY_ATTEMPTS
times instead of being misreported as "still failing".
Re-entrancy guarded: retryInFlight covers the whole attempt chain,
so bursts of online events cannot stack batches.
A newly recorded transient failure arms exponential backoff while the
browser stays online. Healthy sessions hold no polling timer, and a
permanently failing origin stops after MAX_ONLINE_RETRY_ROUNDS.
Routed through the supplied EventGroup so both the listener and
pending retry timers are cleaned up on app dispose (same
pattern as installFocusHandling).
Register a
window 'online'listener that retries every failed loader when connectivity is restored — the trigger half of the failed-load recovery story (SceneLoader.retryAllFailedLoadersis the engine; its own doc names "after connectivity is restored" as the intended use).Behavior:
onlinetransition with failures → toast that a retry is starting, runretryAllFailedLoaders()(the loader serializes it against the update lock internally), and toast the genuine outcome.onlinefires (the reconnect typically happens while an update or LOD refinement is mid-flight — the very situation that produced the failures), andonlinewill not fire again while the browser stays online. A deferred batch therefore re-attempts every DEFERRED_RETRY_DELAY_MS up to MAX_DEFERRED_RETRY_ATTEMPTS times instead of being misreported as "still failing".retryInFlightcovers the whole attempt chain, so bursts ofonlineevents cannot stack batches.Routed through the supplied EventGroup so both the listener and pending retry timers are cleaned up on app dispose (same pattern as
installFocusHandling).