or
https://bugs.webkit.org/show_bug.cgi?id=331092
Created attachment 482283 [details] WKWebView A: Default occlusion detection; recorded video disappears on an inactive Space and recovers on return.
A playing, local non-DRM HTML5 video disappears from an externally captured Safari/WKWebView window when the window is on another macOS Space. The recorded video region becomes blank/dark and recovers on return. Other window content can remain visible. We request investigation of the interaction between media visibility policy and external window capture.
Apple Feedback FB25368989 covers the Safari case. The following newer evidence isolates a visibility-dependent presentation path; it does not establish which component owns the compatibility fix.
python3 -m http.server 8877 --bind 127.0.0.1 --directory <fixture-directory>
http://127.0.0.1:8877/safari-canvas-preflight-v1.html?mode=control
Expected: the selected window's playing video remains available to the active external capture, or a supported capture-aware mechanism is documented.
Actual: video content disappears while away and recovers on return.
_setWindowOcclusionDetectionEnabled:false
The private selector is used only as a diagnostic intervention inside our own WKWebView host, not proposed as a Safari or production recorder API. Both WKWebView runs use the control page with zero Canvas draws. For Safari's Canvas comparison, the Canvas is display:none, drawn exactly once without readback; it does not replace the visible video.
In the actual Safari baseline, view visibility changes to hidden, the media element reports visible=0, and the GPU/AVFoundation path receives setPageIsVisible(false). On return these states become true and the recording recovers. In the Canvas comparison the view still becomes hidden, but the corresponding media/backend false transition was not observed during the away interval.
The matching release implementation of platformSetVisible calls [m_videoLayer setHidden:!isVisible] when a video layer exists. Read-only disassembly of the installed WebCore in our own helper process confirms this implementation. We did not attach to Safari or directly read the historical player's final CALayer.hidden state. Newer main-branch attachment/detachment logic must not be substituted for this release implementation.
[m_videoLayer setHidden:!isVisible]
This supports visibility-driven suppression of video presentation. It does not show that all video sources, DRM content, or all OS/browser versions behave identically. Canvas persistence across source changes, seeking, and long recordings has not been established.
Can external ScreenCaptureKit capture be coordinated with this visibility optimization so the selected window continues to provide video content without becoming foreground? Is a supported browser/platform signal available, or should this require a WebKit and ScreenCaptureKit integration change? We are not requesting permanent background rendering for all windows.
A separate report describes a similar external live-thumbnail use case: https://stackoverflow.com/questions/79949880/macos-26-keep-a-captured-windows-content-live-while-its-on-an-inactive-space . This is a symptom report, not independent confirmation of the mechanism.