Evict hidden browser WebViews under memory pressure

Merged
AU
4mo ago
+272-17

Closes #6584

Summary

  • confirmed by code inspection that PaneMemoryGuardrail covers pane process trees while WKWebView web-content processes are not part of the hidden browser discard timing path
  • added a warning/critical DispatchSourceMemoryPressure hook that immediately fans out to browser panels across registered window tab managers
  • reused the existing hidden browser discard/restore path so eligible non-visible browser panes replace and release their current WKWebView, then reload on return
  • kept visible panes and existing safety blockers intact: loading/provisional navigation, downloads, media capture/playback, popups, devtools, fullscreen, visual automation, closing, and already-discarded panes are not evicted
  • avoided a hardcoded localhost/dev-server port blocklist; the mitigation is content-agnostic

Tests

  • added a test-only commit first for regression provenance
  • added focused coverage for the guardrail memory-pressure callback and hidden/visible browser WebView eviction behavior
  • not run locally per instruction; CI is the validation path

Notes

Observed: hidden browser panes only used the timer-based 5-minute discard path, while system memory pressure had no immediate browser WebView eviction route.
Expected: warning/critical OS memory pressure promptly frees eligible non-visible embedded browser WebViews without changing visible-pane behavior.

View with Codesmith Autofix with Codesmith
Need help on this PR? Tag /codesmith with what you need. Autofix is disabled.

Summary by cubic

Evicts hidden browser WKWebViews on warning/critical system memory pressure while keeping visible panes intact. If a hidden timestamp isn’t recorded or we’re in the post‑wake safety window, we schedule a discard instead and honor the memory‑saver policy.

  • New Features

    • PaneMemoryGuardrail listens for .warning/.critical DispatchSourceMemoryPressure and invokes onSystemMemoryPressure on the main actor.
    • App fans the callback to all TabManager → Workspaces and calls BrowserHiddenWebViewDiscardManager.requestImmediateDiscardIfSafe("system_memory_pressure", now); a single now is forwarded and the total discard count is logged in debug.
    • Discard requires a recorded hidden time; otherwise we schedule using the same now. The post‑wake guard remains in place. Policy is read via injected policyDefaults (UserDefaults).

  • Tests

    • Added BrowserHiddenWebViewDiscardMemoryPressureTests covering immediate discard, scheduling when hidden state is missing, and post‑wake deferral with isolated UserDefaults.

Summary by CodeRabbit

Release Notes

  • New Features

    • Added OS memory pressure support to automatically discard hidden browser webviews during warning/critical memory events.
    • Includes a post-wake grace period to prevent discarding too early, and uses the same hidden-webview policy behavior as normal scheduling.

  • Tests

    • Added coverage for hidden-webview discard under system memory pressure, including immediate-discard when appropriate, no discard when not hidden, and correct scheduling behavior during the post-wake delay window.