All the search results on the internet are for doing the opposite of
what I want - people want firefox, when playing a video, to inhibit
xscreensaver.

It already does that for me.  xscreensaver -verbose:


xscreensaver-systemd: 23:28:03: uninhibited by "firefox-esr" with cookie DEB56E99
xscreensaver-systemd: 23:28:03: inhibit: unable to get pid of "firefox-esr": No data available
xscreensaver-systemd: 23:28:03: inhibited by "firefox-esr" with "video-playing" -> cookie ADCA6C0D
xscreensaver-systemd: 23:28:16: uninhibited by "firefox-esr" with cookie ADCA6C0D
xscreensaver-systemd: 23:28:16: inhibit: unable to get pid of "firefox-esr": No data available
xscreensaver-systemd: 23:28:16: inhibited by "firefox-esr" with "video-playing" -> cookie 57431273
xscreensaver-systemd: 23:28:28: uninhibited by "firefox-esr" with cookie 57431273
xscreensaver-systemd: 23:28:28: inhibit: unable to get pid of "firefox-esr": No data available
xscreensaver-systemd: 23:28:28: inhibited by "firefox-esr" with "video-playing" -> cookie B8F2311F
xscreensaver-systemd: 23:28:41: uninhibited by "firefox-esr" with cookie B8F2311F
xscreensaver-systemd: 23:28:41: inhibit: unable to get pid of "firefox-esr": No data available

Only problem is I'm not playing a video.  Unfortunately, the net is
full of ads, so pretty much every page claims to be "playing a video".
I just want to be able to tell xscreensaver to ignore any calls from
this list of programs:

1) firefox-esr

Oh look at that, end of list.

Yes, I know the proper fix is to tell firefox to give me an option to
not inhibit the screensaver, but we all know how likely that feature
request is to ever be actioned without "CLOSED WONTFIX".

In the meantime, you're trusting every application not to be abusive.
In this case, firefox is being abusing, and there should be an
override to tell the system to ignore it.

"Monkey paw curls."

Yeah, that's awesome, isn't it? I had been under the impression that the bug you are describing only happened with Chromium, not with Firefox. Here's an excerpt from the tragically-long comment at the top of xscreensaver-systemd.c:

 * Twitter (and many other sites) auto-convert GIFs to looping MP4s to
 * save bandwidth.  Chromium inhibits the screen saver any time a Twitter
 * GIF is on screen (either in the browser or in Tweetdeck).
 *
 * The proper way for Chrome to fix this would be to stop inhibiting once
 * the video loops.  That way your multi-hour movie inhibits properly, but
 * your looping GIF only inhibits for the first few seconds.

Firefox, Chrome and Chromium also all will leave the screen permanently inhibiited if they crash, too, which is great.

And Firefox, Chromium and MPV inhibit screen blanking when only *audio* is playing, which makes no damned sense at all.

So, if someone could report bugs against those applications, that would be great.

Also, so that I'm clear on exactly what is happening, can you do a test with Firefox and see if what is going on is, in fact, that it treats any 2-second looping MP4 thumbnail as "playing a movie"? Finding any looping GIF on Twitter is a good way to test it. Then navigate away from that page and see if it uninhibits.

I believe that Firefox didn't used to do this, so it would be interesting to know when they started.

Oh ho ho ho, the list of other programs that fuck this up is so much longer than that. It's basically all of them.

Your best bet is probably just "rm xscreensaver-systemd". This will unfortunately have the side effect that your screen will not auto-lock when you close the laptop lid.

That's not actually the fix, it's just that they are inhibiting it in the stupidest possible way. Maybe "be less stupid" will get more traction than "stop". We can dare to dream.

"Monkey paw curls."

Yeah, that's awesome, isn't it? I had been under the impression that the bug you are describing only happened with Chromium, not with Firefox. Here's an excerpt from the tragically-long comment at the top of xscreensaver-systemd.c:

 * Twitter (and many other sites) auto-convert GIFs to looping MP4s to
 * save bandwidth.  Chromium inhibits the screen saver any time a Twitter
 * GIF is on screen (either in the browser or in Tweetdeck).
 *
 * The proper way for Chrome to fix this would be to stop inhibiting once
 * the video loops.  That way your multi-hour movie inhibits properly, but
 * your looping GIF only inhibits for the first few seconds.

Firefox, Chrome and Chromium also all will leave the screen permanently inhibiited if they crash, too, which is great.

And Firefox, Chromium and MPV inhibit screen blanking when only *audio* is playing, which makes no damned sense at all.

So, if someone could report bugs against those applications, that would be great.

Also, so that I'm clear on exactly what is happening, can you do a test with Firefox and see if what is going on is, in fact, that it treats any 2-second looping MP4 thumbnail as "playing a movie"? Finding any looping GIF on Twitter is a good way to test it. Then navigate away from that page and see if it uninhibits.

I believe that Firefox didn't used to do this, so it would be interesting to know when they started.

Oh ho ho ho, the list of other programs that fuck this up is so much longer than that. It's basically all of them.

Your best bet is probably just "rm xscreensaver-systemd". This will unfortunately have the side effect that your screen will not auto-lock when you close the laptop lid.

That's not actually the fix, it's just that they are inhibiting it in the stupidest possible way. Maybe "be less stupid" will get more traction than "stop". We can dare to dream.

On Tue, 19 Apr 2022, Jamie Zawinski wrote:

Never got around to replying to this, sorry, although I did submit bugs to
firefox.

In my case, it's culprits like https://theage.com.au, which are full of
ads and occasional auto-looping videos/gifs, combined with a 5ish minute
auto-reload.  So the screensaver would be poked every 5 minutes regardless
of such a fix.

Not sure that's the case - xdg-screensaver takes a windowid, and I'm
pretty sure I tested that when that windowid disappears due to crash, the
lock is released.

This audio aspect has finally been addressed, I believe, in firefox - my
original bug, which got auto-routed to the wrong component, "fixed", then
closed:

https://bugzilla.mozilla.org/show_bug.cgi?id=1749187


A clone of that properly routed, dealing with the video component, hasn't
been acknowledged yet:
https://bugzilla.mozilla.org/show_bug.cgi?id=188526

(firefox 1744641 deals with the stupid "human readable" text string simply
reading: "Playing video" or "video-playing" rather than something useful)


However, I don't know whether it's a result of one of my recent changes to
my own screensaver setup, a lack of me opening pages that embed
auto-looping video, or an undocumented change somewhere between firefox
115.15.0esr-1~deb12u1 and current 128.3.1esr-1~deb12u1, but my the
logfiles for my workaround for this bug show this had stopped affecting me
sometime recently (I had been running xscreensaver under a
watchdog that monitors for "inhibited by" | grep "$prohibited_items" per
my config here:
https://github.com/spacelama/ansible-initial-server-setup/blob/master/files/homes.desktop/bin/runxscreensaver-monitor
)