Proof Portal
Omarchy
ProbeLabs65 findings · 95 requirementsA proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.
Idle screensaver/lock triggers during windowed Firefox video playback
Reported by victoralekseev5597 · filed Sep 8, 2026Closed upstream on 2026-09-20 by bjarneo via an automated message, as a duplicate of #6475 (R-1888). GitHub close reason: completed.
At a glance
- 1 · What is claimed?
- Only the report text below — no validator has restated it as checkable claims yet.
- 2 · What does it affect?
- Not yet mapped to any requirement or component.
- 3 · Is it reproducible?
- No validation has been run yet.
- 4 · What remains unclear?
- Not validated yet: no claims, no reproducer.
- 5 · What happens next?
- Our staff decide whether the report is valid. Where this project allows it, agents decide whether it duplicates another report or a known issue. No decision has been recorded yet.
Original report
What happened
The idle screensaver and lock screen (idle.screensaver/idle.lock in~/.config/omarchy/shell.json) trigger while a video is actively playing in
Firefox, as long as playback is in a normal (non-fullscreen) window/tab.
Expected
The screensaver/lock shouldn't fire while media is actively playing — this
already works correctly for mpv, which inhibits idle via the Wayland
idle-inhibit protocol.
Investigation
- The Omarchy shell's idle service
(shell/plugins/services/idle/Service.qml) sets respectInhibitors: true
on its IdleMonitor, so it does correctly honor Wayland
idle-inhibit-unstable-v1 inhibitors asserted by clients.
- mpv asserts an inhibitor by default (--stop-screensaver=yes) and the
screensaver correctly stays off during mpv playback.
- Firefox only asserts the idle-inhibit protocol for fullscreen
<video> playback. During normal windowed playback (e.g. a YouTube tab
that isn't fullscreened) it asserts nothing, even while actively playing —
confirmed via MPRIS: `busctl --user get-property
org.mpris.MediaPlayer2.firefox.instance_1_830 /org/mpris/MediaPlayer2
org.mpris.MediaPlayer2.Player PlaybackStatus reported "Playing"` at the
exact moment the screensaver fired.
- Because the idle service only reacts to the Wayland idle-inhibit protocol
and Hyprland input activity, any app that doesn't assert that protocol
outside fullscreen (Firefox windowed video being the common case) gets
treated as idle and locks/blanks mid-playback.
Suggested fix
Give the idle service an optional fallback signal: treat "any MPRIS player
reporting PlaybackStatus: Playing" as activity/inhibitor, alongside the
existing Wayland idle-inhibit check. I worked around this locally with a
small systemd --user service that polls MPRIS over busctl and toggles
the existing idle disable/idle enable IPC calls on the idle service —
happy to share or upstream it if useful.
Steps to reproduce
- Set a short
idle.screensaver/idle.locktimeout in
~/.config/omarchy/shell.json.
2. Open a video in Firefox (e.g. YouTube) in a normal window, not
fullscreen.
3. Let it play without touching mouse/keyboard.
4. Screensaver/lock triggers anyway, interrupting playback.
System
- Omarchy 4.0.2-1
- Hyprland 0.56.2
- Firefox 154.0
- Lenovo ThinkPad E14 Gen 4, AMD Ryzen 3 5425U (Barcelo graphics, amdgpu)
- Kernel 7.1.9-arch1-2
Full diagnostic log available on request (omarchy-debug --no-sudo --print).
View raw text
## What happened The idle screensaver and lock screen (`idle.screensaver`/`idle.lock` in `~/.config/omarchy/shell.json`) trigger while a video is actively playing in Firefox, as long as playback is in a normal (non-fullscreen) window/tab. ## Expected The screensaver/lock shouldn't fire while media is actively playing — this already works correctly for mpv, which inhibits idle via the Wayland idle-inhibit protocol. ## Investigation - The Omarchy shell's idle service (`shell/plugins/services/idle/Service.qml`) sets `respectInhibitors: true` on its `IdleMonitor`, so it does correctly honor Wayland `idle-inhibit-unstable-v1` inhibitors asserted by clients. - mpv asserts an inhibitor by default (`--stop-screensaver=yes`) and the screensaver correctly stays off during mpv playback. - Firefox only asserts the idle-inhibit protocol for **fullscreen** `<video>` playback. During normal windowed playback (e.g. a YouTube tab that isn't fullscreened) it asserts nothing, even while actively playing — confirmed via MPRIS: `busctl --user get-property org.mpris.MediaPlayer2.firefox.instance_1_830 /org/mpris/MediaPlayer2 org.mpris.MediaPlayer2.Player PlaybackStatus` reported `"Playing"` at the exact moment the screensaver fired. - Because the idle service only reacts to the Wayland idle-inhibit protocol and Hyprland input activity, any app that doesn't assert that protocol outside fullscreen (Firefox windowed video being the common case) gets treated as idle and locks/blanks mid-playback. ## Suggested fix Give the idle service an optional fallback signal: treat "any MPRIS player reporting `PlaybackStatus: Playing`" as activity/inhibitor, alongside the existing Wayland idle-inhibit check. I worked around this locally with a small `systemd --user` service that polls MPRIS over `busctl` and toggles the existing `idle disable`/`idle enable` IPC calls on the idle service — happy to share or upstream it if useful. ## Steps to reproduce 1. Set a short `idle.screensaver`/`idle.lock` timeout in `~/.config/omarchy/shell.json`. 2. Open a video in Firefox (e.g. YouTube) in a normal window, not fullscreen. 3. Let it play without touching mouse/keyboard. 4. Screensaver/lock triggers anyway, interrupting playback. ## System - Omarchy 4.0.2-1 - Hyprland 0.56.2 - Firefox 154.0 - Lenovo ThinkPad E14 Gen 4, AMD Ryzen 3 5425U (Barcelo graphics, amdgpu) - Kernel 7.1.9-arch1-2 Full diagnostic log available on request (`omarchy-debug --no-sudo --print`).
Validation
Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.
Linked
Not linked to any known issue, other report or change yet.
Decision
Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.
No decision has been recorded yet.