[Bug]: Desktop app held a Chromium "Video Wake Lock" for 14 hours, so the Mac never turned off its display or locked #15343

Activity

1. juliusmarminge commented on Oct 3, 2026

   

   juliusmarminge

   on Oct 3, 2026

   Member

   More actions

   Note

   Grok responding on behalf of Julius.

   Triage

   Thanks for the pmset trace and the careful write-up, @reowens! This is a real bug on current main (5e35272fda) and on v0.0.44, and I didn't find a duplicate. As you suspected, the app never asks for this lock itself. There's no powerSaveBlocker and no navigator.wakeLock.request in the tree. A NoDisplaySleepAssertion named "Video Wake Lock" is Chromium's own display-sleep lock for an HTMLVideoElement.

   Chromium holds that lock only while the element is actually playing, the document is running, and one of these is true:

   • the element is in picture-in-picture, or
   • the page is visible and the video is audible (it has an audio track with volume above 0), or
   • the page is visible and the video is both mostly on screen (about 75%) and large (about 20% of the viewport).

   A MediaStream skips the size check but still has to be visible or audible. The lock drops when those conditions stop being true. In your log it dropped in the same second the process quit, so the element stayed alive until then.

   Where it can come from

   Two parts of the app can do this without an obvious video on screen:

   • Chat, pull-request, and file videos go through MediaVideoPlayer (apps/web/src/components/media/MediaVideoPlayer.tsx). It pauses on unmount and when the document is hidden, including fullscreen, but not when the video scrolls out of view. An unmuted clip with an audio track keeps the lock while the window is visible, even after it scrolls away, until it ends, pauses, or unmounts. Inline chat videos aren't muted and can be up to 30rem, which is big enough to qualify while on screen. File previews also have a raw <video controls> in AttachmentFilePreview with no hidden-document pause. Playback that never reaches ended (a long file, a live source, or a stalled playing element) holds the lock until quit. The message list isn't virtualized, so a started video stays mounted after you scroll past it.
   • Integrated-browser guests can hold it while they're composited inside the window. A tab that's showing does, and so does a tab that recording, preview automation, or picture-in-picture marks as rendering-active. In that case HostedBrowserWebview parks a full-size visibility: visible webview at the top-left of the window, behind the UI (z-index: -1), so Electron keeps compositing it. A playing video in that guest then satisfies Chromium even while you're looking at chat. On macOS, inactive tabs also stay visibility: visible (the Electron 43 blanking workaround, already in v0.0.44), but they're placed fully outside the window and Electron stops compositing them, so that path shouldn't hold the lock unless something marks the tab rendering-active.

   Less likely sources

   The recording compositor is a weak fit. createRecordingCompositor plays a muted <video> that's never inserted into the document, and only when key or mouse decoration is on. Muted and not intersecting, it shouldn't qualify. The coreaudiod preventuseridledisplaysleep assertions are a separate mechanism: your log shows the display turning off while some were held, and they were released two seconds after quit, after the video lock. The shared notification AudioContext in threadNotifications.ts is never closed, but that isn't what kept the display on.

   Reading the timeline

   The sub-second locks at 22:48:13 and 22:48:19 fit a video that qualified and then paused or left view within the same second. The 14h 15m lock started at 23:02:53, three seconds after the display turned on, and lasted until exit, so something entered playing then and never paused. The log can't tell us whether that was a chat or file video or a browser guest, but it does rule out an app-level sleep blocker.

   This also isn't the same as #663. That request was about prevent-app-suspension during an active turn, so the display can still sleep and lock. This bug breaks that expectation from the other direction, because Chromium's video lock is prevent-display-sleep.

   Likely fix area

   • One option is to pause MediaVideoPlayer (and the raw preview <video>) when it scrolls out of view, not only on unmount or a hidden document.
   • Another is to check what a rendering-active browser guest can play while it's parked behind the UI.

   Until then, quitting the app or locking with Control-Command-Q is the right workaround. A maintainer will decide on the fix direction.
2. juliusmarminge

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   on Oct 3, 2026