User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:103.0) Gecko/20100101 Firefox/103.0

Steps to reproduce:

• Using the Firefox snap, visit youtube.com or another site with video
• Wait for screensaver to kick in

Actual results:

Screensaver kicks in as normal

Expected results:

Screensaver should be inhibited while video is playing

This works as I would expect when using the regular download: it only seems to be a problem when using the snap (possibly Firefox can't access the dbus from within the snap?)

Rather than actually waiting for the screensaver to kick in, it's possible to watch for inhibitors with

watch dbus-send --print-reply --dest=org.freedesktop.PowerManagement /org/freedesktop/PowerManagement/Inhibit org.freedesktop.PowerManagement.Inhibit.GetInhibitors

To add a little extra data to this, running Firefox with MOZ_LOG=LinuxWakeLock:5 shows that it is trying to send screensaver inhibit calls:

[Parent 288754: Main Thread]: D/LinuxWakeLock WakeLockListener video-playing state locked-foreground
[Parent 288754: Main Thread]: D/LinuxWakeLock shouldLock 1
[Parent 288754: Main Thread]: D/LinuxWakeLock SendInhibit(): FreeDesktopScreensaver
[Parent 288754: Main Thread]: D/LinuxWakeLock SendInhibit(): GNOME
[Parent 288754: Main Thread]: D/LinuxWakeLock SendInhibit(): FreeDesktopPower
[Parent 288754: Main Thread]: D/LinuxWakeLock WakeLockListener video-playing state unlocked
[Parent 288754: Main Thread]: D/LinuxWakeLock shouldLock 0

but snappy-debug shows that at least some of these calls are being denied by AppArmor:

= AppArmor =
Time: Feb 21 11:07:19
Log: apparmor="DENIED" operation="dbus_method_call" bus="session" path="/org/freedesktop/PowerManagement/Inhibit" interface="org.freedesktop.PowerManagement.Inhibit" member="Inhibit" mask="send" name="org.freedesktop.PowerManagement" pid=288754 label="snap.firefox.firefox" peer_pid=2736 peer_label="unconfined"
DBus access

Further update. If I run the snap firefox binary, but not as a snap, then the screensaver is correctly inhibited.

Run the snap binary, but not as a snap, and with a new temporary profile instance:

MOZ_LOG=LinuxWakeLock:5 /snap/firefox/current/usr/lib/firefox/firefox --no-remote -profile -new-instance $HOME/tmpmoz

Confirm that the screensaver is not inhibited (on XFCE):

dbus-send --print-reply --dest=org.xfce.ScreenSaver / org.xfce.ScreenSaver.GetInhibitors
method return time=1676990440.798691 sender=:1.35 -> destination=:1.6142 serial=327 reply_serial=2
array [
]

Start playing a video from YouTube in the Firefox window, and then run the screensaver inhibit check command again:

dbus-send --print-reply --dest=org.xfce.ScreenSaver / org.xfce.ScreenSaver.GetInhibitors
method return time=1676990436.800123 sender=:1.35 -> destination=:1.6141 serial=325 reply_serial=2
array [
string "Application="xfce4-power-manager"; Since="2023-02-21T14:40:35Z"; Reason="Inhibit requested";"
]

That is: Firefox is correctly telling the screensaver to inhibit, just as it should be. After stopping the video, the GetInhibitors D-Bus call is correctly returning empty.

However, if I run the Firefox snap normally (i.e., as a snap) then it does not inhibit the screensaver; GetInhibitors is always empty, even when a video is playing.

Note that it's not Firefox itself that's listed as an inhibitor; it's xfce-power-manager. This may mean that the problem is that Firefox doesn't call XFCE's screensaver D-Bus Inhibit directly, but instead calls FreeDesktopPower (provided by xfce-power-manager) and the power manager inhibits the screensaver, but the call to powermanager is blocked by snap packaging, as in the previous comment.

This problem itself (of the snap apparmor packaging blocking the d-bus powermanager.inhibit call) may be a bug in snapd; https://irclogs.ubuntu.com/2023/02/21/%23snappy.html has discussion on this, and alexmurray submitted https://github.com/snapcore/snapd/pull/12580 as a patch to perhaps fix this issue in snapd. So on XFCE this certainly isn't a problem in Firefox itself, and it's either a problem in Firefox's snap packaging or a problem in snapd. It's not clear whether this problem also exhibits on other desktops, possibly with other causes.

This was fixed by XFCE people. Other desktop should fix it on their side.