I have this issue as well. When a video is played Firefox shows up as blocking sleep/screen locking in the battery applet, but when the timeout finishes it disappears and fails to turn off the screen.

ive had this same issue for a while now. my system specs:

Operating System: Fedora Linux 40
KDE Plasma Version: 6.0.4
KDE Frameworks Version: 6.1.0
Qt Version: 6.7.0
Kernel Version: 6.8.9-300.fc40.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 4 × Intel® Core™ i7-5600U CPU @ 2.60GHz
Memory: 11.6 GiB of RAM
Graphics Processor: Mesa Intel® HD Graphics 5500

firefox flatpak info and permissions: https://paste.debian.net/hidden/83f3916b/

someone posted on reddit that setting a name in flatpak > session bus > talks > "org.freedesktop.ScreenSaver" is a workaround. in a quick test it seems it does inhibit the lock screen while video is playing in firefox for me.

That makes this a packaging bug in Firefox's Flatpak manifest. Can you report this upstream, or submit a patch? See https://github.com/flathub/org.mozilla.firefox.BaseApp/pulls

(In reply to Nate Graham from comment #4)
> That makes this a packaging bug in Firefox's Flatpak manifest. Can you
> report this upstream, or submit a patch? See
> https://github.com/flathub/org.mozilla.firefox.BaseApp/pulls

yep. found it here: https://bugzilla.mozilla.org/show_bug.cgi?id=1882641

*** Bug 433452 has been marked as a duplicate of this bug. ***

(In reply to Nate Graham from comment #4)
> That makes this a packaging bug in Firefox's Flatpak manifest. Can you
> report this upstream, or submit a patch? See
> https://github.com/flathub/org.mozilla.firefox.BaseApp/pulls

I disagree with this perspective.

> - The battery and brightness applet displays a message, that firefox prevents screen lock
> - The screen locks anyway

If KDE says in its UI "Firefox Web Browser is currently blocking sleep and screen locking (video-playing)" (**and it does**), it /should be/ suppressing power management.

Also, this is not just a Firefox thing, this affects other things like Moonlight.

It's been a very frustrating experience trying to play a game with a controller and then having the screen shut off because the controller doesn't count as activity and the "Moonlight is currently blocking sleep and screen locking (Playing a game)" message in KDE's UI is a lie.

If adding a permission in the Flatpak packaging fixes the bug that power management isn't inhibited correctly, then the bug is caused by incorrect Flatpak packaging.

There may also be an opportunity to clean something up on our side such that when that permission is missing, the Power & Battery widget won't even show the false inhibition notice in the first place. That would be a separate issue. I'll leave it up to Natalie and Jakob as to whether they think that's worth doing.

> Also, this is not just a Firefox thing, this affects other things like Moonlight.
What you describe next is a different issue: Bug 328987.

(In reply to Nate Graham from comment #9)
> If adding a permission in the Flatpak packaging fixes the bug that power
> management isn't inhibited correctly, then the bug is caused by incorrect
> Flatpak packaging.
> 
> There may also be an opportunity to clean something up on our side such that
> when that permission is missing, the Power & Battery widget won't even show
> the false inhibition notice in the first place. That would be a separate
> issue. I'll leave it up to Natalie and Jakob as to whether they think that's
> worth doing.
> 
> > Also, this is not just a Firefox thing, this affects other t

(In reply to Nate Graham from comment #9)
> If adding a permission in the Flatpak packaging fixes the bug that power
> management isn't inhibited correctly, then the bug is caused by incorrect
> Flatpak packaging.
> 
> There may also be an opportunity to clean something up on our side such that
> when that permission is missing, the Power & Battery widget won't even show
> the false inhibition notice in the first place. That would be a separate
> issue. I'll leave it up to Natalie and Jakob as to whether they think that's
> worth doing.

what is plasma doing to decide that the app is inhibiting?

I don't know, but hopefully either Natalie or Jabob does, hence why I CCd them :)

(In reply to Nate Graham from comment #9)
> If adding a permission in the Flatpak packaging fixes the bug that power
> management isn't inhibited correctly, then the bug is caused by incorrect
> Flatpak packaging.
> 
> There may also be an opportunity to clean something up on our side such that
> when that permission is missing, the Power & Battery widget won't even show
> the false inhibition notice in the first place. That would be a separate
> issue. I'll leave it up to Natalie and Jakob as to whether they think that's
> worth doing.

The latter part is what I'm referring to. I likely would have figured this out in Bug 433452 (way back in 2021) if Plasma was actually telling the truth about the situation. 

Instead, Plasma said that it was doing something that it clearly wasn't and we've had annoying packaging bugs in the ecosystem for AT LEAST 3 YEARS.

This is FAR from the first time I've been incredibly frustrated with KDE's power management reporting and documentation. I had to do all the grunt work several years ago communicating with the Plex team to get Plex to work with Plasma's power management https://forums.plex.tv/t/linux-flatpak-player-doesnt-inhibit-power-management/804528.

> What you describe next is a different issue: Bug 328987.

It is but it also isn't because SDL (powering moonlight under the hood) is actively trying to stop the screen saver from working. Plasma is reporting that it's succeeding at that, and it fails anyways.

The SDL code is seemingly even capable of using org.freedesktop.ScreenSaver but seemingly neglects to use that code path if Inhibit succeeds:
https://github.com/libsdl-org/SDL/blob/17965117824d82afd0f6692c8871510f942270f7/src/core/linux/SDL_dbus.c#L367
https://github.com/libsdl-org/SDL/blob/17965117824d82afd0f6692c8871510f942270f7/src/core/linux/SDL_dbus.c#L460

Multiple major developers are clearly genuinely being confused about what signal they need to be sending for the behavior they want.

How Plasma responds to Inhibit, both in the UI and power management side is surely entirely within its control. This is no different to me than if Dolphin said it deleted a file but the file is still in the directory.

I'm grateful for all the work various people in this community do, but can we please accept there's a *real* bug here and that the Plasma UI should not actively lie about the behavior of its own power management system?

Sure. Like I said, please open a new bug report for it. What Plasma *does* and what Plasma *displays to the user* are different things. This bug report is about the former case; you want it to do something different in the latter case. And that's valid, but it needs a different bug report.

Bug 487118 filed.

I in looking at this a little closer do think this is actually the real bug though (not the display).

https://github.com/flatpak/xdg-desktop-portal/commit/f57ed505719f7371496c1b0b843d46e160bd6253

> This lets sandboxed apps inhibit session status changes, such as suspend or idle. This is the API that lets movie players prevent the screensaver from kicking in halfway through the movie.

org.freedesktop.portal.Inhibit was pretty clearly intended to affect the Screen Saver

*** Bug 463017 has been marked as a duplicate of this bug. ***

It turns out you were right all along, sorry. Thankfully, the root cause that you identified was just fixed today for Plasma 6.1.4. See Bug 486506.

*** This bug has been marked as a duplicate of bug 486506 ***