Offline indicator latches permanently when the initial connectivity probe fails

Summary

OfflineIndicator runs a one-shot connectivity probe on mount when navigator.onLine === true. If that probe rejects — most plausibly because the WP REST root for a Jetpack-tunneled site takes longer than the hard 5s timeout to respond on first hit — setIsConnected(false) latches and the "Working Offline" bar stays up indefinitely. The only path back to connected is a browser online event, which is fired exclusively on a real offline → online transition. If navigator.onLine never went to false, the event never fires, the probe never re-runs, and the editor displays "Working Offline" while the network is perfectly fine.

Repro

1. Editor on a Jetpack-connected self-hosted site whose JP tunnel happens to cold-start slowly (or any condition where the first HEAD to siteApiRoot exceeds 5s).

2. Open the editor. "Working Offline" bar appears.

3. From DevTools attached to the WebView:

   ({navigatorOnLine: navigator.onLine, probeUrl: window.GBKit.siteApiRoot})
   

   → {navigatorOnLine: true, probeUrl: "https://<site>/wp-json/"}. The browser thinks it's online; the URL is correct.

4. Manually re-run the probe with the same parameters as probeConnectivity():

   await fetch(window.GBKit.siteApiRoot, {method:'HEAD', mode:'no-cors', cache:'no-store', signal: AbortSignal.timeout(5000)});
   

   → resolves in ~1.6s. Connectivity is fine now; it wasn't at mount.

5. Force a re-probe:

   window.dispatchEvent(new Event('online'));
   

   → bar disappears immediately. Confirms the state is latched, not the network.

Verified on org.wordpress.gutenbergkit:android:v0.17.2 in the WordPress-Android jetpack.wpmt.co test site editor.

Root Cause

src/components/offline-indicator/index.jsx, useNetworkConnectivity:

useEffect( () => {
    const abortController = new AbortController();

    if ( navigator.onLine ) {
        probeConnectivity().then( ( connected ) => {
            if ( ! abortController.signal.aborted ) {
                setIsConnected( connected );
            }
        } );
    }

    const handleOnline = async () => { … };       // only fires on offline → online
    const handleOffline = () => setIsConnected( false );

    window.addEventListener( 'online', handleOnline );
    window.addEventListener( 'offline', handleOffline );
    …
}, [] );

A single probe drives the only setIsConnected(true) path on mount. Recovery only happens via online, which Chrome dispatches strictly on a real network-interface transition. navigator.onLine staying true the whole time means there's nothing to dispatch.

The 5s timeout is treated as hard authority. A cold REST root or a momentary DNS lag is enough to flip the state and there's no path back.

Suggested Fix

Several non-exclusive options:

1. Soft initial timeout / retry-once before latching. If the first probe rejects with TimeoutError, retry once after a short delay (1–2s) before committing setIsConnected(false). Cheap and catches the common cold-start case.

2. Periodic re-probe while latched offline. A modest backoff timer (e.g. 5s → 15s → 30s capped) that only runs while isConnected === false self-heals the latch without trusting the browser event. No cost while online.

3. Re-probe on user-driven signals. visibilitychange returning to visible is a strong "the user just looked at the editor" cue; pageshow, focus on the WebView, or a debounced input/scroll handler would catch the cases where the user has clearly resumed activity. Cheap and well-bounded.

4. Probe interpretation: distinguish "couldn't reach API root" from "no network at all." If the probe rejects with a network error vs. a timeout vs. an HTTP-style error, those imply different recovery strategies. A TypeError from fetch (no network interface) is much more likely to require an online event. A TimeoutError is much more likely to require retry.

(1) alone would have prevented this incident. (2) is the most robust against future regressions of this shape.

Affected

• All consumers of OfflineIndicator (i.e., every site loaded in GutenbergKit). Worst case where the indicator persists is sites with a non-trivial cold-path to siteApiRoot — Jetpack-connected self-hosted sites in particular.

Start in src/components/offline-indicator/index.jsx at useNetworkConnectivity and inspect how the initial probe, online event, and offline event update the indicator. Reproduce an initial probe failure while navigator.onLine remains true, then verify that the chosen recovery behavior clears the "Working Offline" bar without requiring an online event.