What are the ways you notice that it is not blocked?

The bug is similar to this bug -> (In reply to Natalie Clarius from comment #1)
> What are the ways you notice that it is not blocked?

First, the screen is locked after 5 minutes, and I disabled "Screen Locking", then the screen was dimmed after 5 minutes, and it was turned off after 10 minutes, so I knew that power management is not inhibited.

I was playing an audio file using Elisa earlier today, and my machine did not go to sleep, so I did not suspect anything wrong until I used Firefox (Flatpak) and I discovered this issue.

I installed Kubuntu 24.04 yesterday (fresh install, no upgrade).

Typo: the screen was locked after 5 minutes.

I can confirm this on my Steam Deck. I had Netflix playing in Firefox. The Plasma power widget even shows the message saying Firefox is blocking but then 1 minute later my display dims and then turns off.

The same thing happens to me with my 3 Linux systems. When playing a YouTube video, the screensaver does not automatically inhibit and the session closes after 5 minutes. I am also using the flatpak version.

Perhaps the sandbox prevents it from working properly like it breaks Plasma Browser Integration, too....

I get the same behaviour with the flatpaked version of SameBoy (screen goes black while playing with Gamepad despite SameBoy is listed as "blocking screen locking and suspend" in systray).

However, if I watch videos with Freetube (also Flatpak), suspend inhibition works correct (screen stays on).

My setup:
* Kubuntu 24.04
* self-build Plasma 6.0.90, Frameworks 6.4.0 and Qt 6.7.2
* Wayland session

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

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

Hello, everyone. Seems like this is a result of misconfiguration on the flatpak package's maintainers. Add permission to talk with org.freedesktop.ScreenSaver of Session Bus and Firefox should prevent the screen from locking again if you watch videos.

(In reply to Valeriy from comment #10)
> Hello, everyone. Seems like this is a result of misconfiguration on the
> flatpak package's maintainers. Add permission to talk with
> org.freedesktop.ScreenSaver of Session Bus and Firefox should prevent the
> screen from locking again if you watch videos.

Have you tested this with a local build or confirmed this from Mozilla on their Bugzilla tracker?

(In reply to Justin Zobel from comment #11)
> (In reply to Valeriy from comment #10)
> > Hello, everyone. Seems like this is a result of misconfiguration on the
> > flatpak package's maintainers. Add permission to talk with
> > org.freedesktop.ScreenSaver of Session Bus and Firefox should prevent the
> > screen from locking again if you watch videos.
> 
> Have you tested this with a local build or confirmed this from Mozilla on
> their Bugzilla tracker?

I've only tested this locally on my machine.

(In reply to Valeriy from comment #12)
> (In reply to Justin Zobel from comment #11)
> > (In reply to Valeriy from comment #10)
> > > Hello, everyone. Seems like this is a result of misconfiguration on the
> > > flatpak package's maintainers. Add permission to talk with
> > > org.freedesktop.ScreenSaver of Session Bus and Firefox should prevent the
> > > screen from locking again if you watch videos.
> > 
> > Have you tested this with a local build or confirmed this from Mozilla on
> > their Bugzilla tracker?
> 
> I've only tested this locally on my machine.

Well if it works there I'd suggest reporting to Mozilla so they can integrate it into their Flatpak build.

(In reply to Justin Zobel from comment #13)
> (In reply to Valeriy from comment #12)
> > (In reply to Justin Zobel from comment #11)
> > > (In reply to Valeriy from comment #10)
> > > > Hello, everyone. Seems like this is a result of misconfiguration on the
> > > > flatpak package's maintainers. Add permission to talk with
> > > > org.freedesktop.ScreenSaver of Session Bus and Firefox should prevent the
> > > > screen from locking again if you watch videos.
> > > 
> > > Have you tested this with a local build or confirmed this from Mozilla on
> > > their Bugzilla tracker?
> > 
> > I've only tested this locally on my machine.
> 
> Well if it works there I'd suggest reporting to Mozilla so they can
> integrate it into their Flatpak build.

In a Flatpak environment, they should probably use the `org.freedesktop.portal.Inhibit` interface [1] rather than `org.freedesktop.Inhibit`. KDE's portal implementation exists [2], so in theory this would allow the most cross-platform implementation as `org.freedesktop.Inhibit` is now considered legacy for non-sandboxed apps (those should use the systemd inhibit interface [3] instead). But I agree with Justin that Firefox developers should have a look at why their Flatpak build isn't using the portal API.

[1] https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.Inhibit.html
[2] https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/blob/master/src/inhibit.cpp
[3] https://www.freedesktop.org/software/systemd/man/latest/org.freedesktop.login1.html

Someone report or fix upstream, please.

https://bugs.kde.org/show_bug.cgi?id=472541#c8 had an interesting observation, in that KDE implements Wayland inhibition locks correctly but some apps or inhibit helpers don't associate them to focused Wayland surfaces and thus the lock is not respected by the compositor. https://codeberg.org/river/river/issues/1079#issuecomment-2013817 has another comment about this. https://bugzilla.mozilla.org/show_bug.cgi?id=1877022 was a Firefox issue for that problem.

This leads to the actual source code in https://hg.mozilla.org/mozilla-central/file/tip/widget/gtk/WakeLockListener.cpp which shows that Firefox does implement support for the xdg portal D-Bus API, however only as a fallback after the old-school `org.freedesktop.Inhibit` D-Bus API has been tried. The aforementioned Wayland API is yet different and only a last-resort fallback, so probably not further relevant for the purpose of this bug.

In theory, Firefox should be trying the various D-Bus interfaces in order, and switch to the next candidate if the previous ones don't work. We should trace D-Bus calls via dbus-monitor before punting responsibility onto Firefox, especially if a "blocking sleep and screen locking" message appears in the Battery applet.

> especially if a "blocking sleep and screen locking" message appears in the Battery applet.
Indeed, that happens. So the message appears but isn't accurate.

I ran dbus-monitor to see what's going on. It makes sense now and I've got a fix. The disconnect is that xdg-desktop-portals-kde receives an `Inhibit` request with flags 8 from Firefox, which according to the linked docs means inhibiting "Idle":

https://docs.flatpak.org/en/latest/portal-api-reference.html#gdbus-org.freedesktop.portal.Inhibit

Following that, xdg-desktop-portals-kde calls PowerDevil's `AddInhibition` with a "policies" argument of value 1, a.k.a. "InterruptSession". PowerDevil receives and registers it as requested. You'd think that this would keep the locker from firing? No, in fact, what "InterruptSession" does is to prevent sleep, not idle. The XDG portals API has a different flag for that, called "Suspend" with value 4, not 8.

Hence the fix is to ask PowerDevil for the correct policy, confusingly called "ChangeScreenSettings" with value 4, not 1. We're already using this for logind "idle" inhibitors, so I'm pretty confident that it's the right pick also for portals "Idle".

This also explains why the applet was showing an indicator: PowerDevil was in fact inhibiting, except not against screen locking but merely against system sleep.

Here's the relevant dbus-monitor output for reference, from Firefox registering the inhibition to PowerDevil receiving it:

method call time=1722263501.828060 sender=:1.262 -> destination=:1.6 serial=263 path=/org/freedesktop/portal/desktop; interface=org.freedesktop.portal.Inhibit; member=Inhibit
   string "org.mozilla.firefox"
   uint32 8
   array [
      dict entry(
         string "reason"
         variant             string "video-playing"
      )
   ]
method call time=1722263501.828599 sender=:1.6 -> destination=org.freedesktop.DBus serial=9496 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
   string "type='signal',sender='org.freedesktop.impl.portal.desktop.kde',interface='org.freedesktop.impl.portal.Request',path='/org/freedesktop/portal/desktop/request/1_262/t/3738610708'"
method return time=1722263501.828618 sender=org.freedesktop.DBus -> destination=:1.6 serial=4294967295 reply_serial=9496
method call time=1722263501.828625 sender=:1.6 -> destination=org.freedesktop.DBus serial=9497 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=StartServiceByName
   string "org.freedesktop.impl.portal.desktop.kde"
   uint32 0
method return time=1722263501.828640 sender=org.freedesktop.DBus -> destination=:1.6 serial=4294967295 reply_serial=9497
   uint32 2
method call time=1722263501.828871 sender=:1.6 -> destination=org.freedesktop.DBus serial=9498 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=GetNameOwner
   string "org.freedesktop.impl.portal.desktop.kde"
method return time=1722263501.828888 sender=org.freedesktop.DBus -> destination=:1.6 serial=4294967295 reply_serial=9498
   string ":1.31"
method return time=1722263501.829171 sender=:1.6 -> destination=:1.262 serial=9499 reply_serial=263
   object path "/org/freedesktop/portal/desktop/request/1_262/t/3738610708"
method call time=1722263501.829311 sender=:1.6 -> destination=:1.9 serial=9500 path=/org/freedesktop/impl/portal/PermissionStore; interface=org.freedesktop.impl.portal.PermissionStore; member=Lookup
   string "inhibit"
   string "inhibit"
error time=1722263501.829910 sender=:1.9 -> destination=:1.6 error_name=org.freedesktop.portal.Error.NotFound reply_serial=9500
   string "No entry for inhibit"
method call time=1722263501.830200 sender=:1.6 -> destination=:1.31 serial=9501 path=/org/freedesktop/portal/desktop; interface=org.freedesktop.impl.portal.Inhibit; member=Inhibit
   object path "/org/freedesktop/portal/desktop/request/1_262/t/3738610708"
   string "org.mozilla.firefox"
   string "org.mozilla.firefox"
   uint32 8
   array [
      dict entry(
         string "reason"
         variant             string "video-playing"
      )
   ]
method call time=1722263501.830491 sender=:1.31 -> destination=org.kde.Solid.PowerManagement serial=13663 path=/org/kde/Solid/PowerManagement/PolicyAgent; interface=org.kde.Solid.PowerManagement.PolicyAgent; member=AddInhibition
   uint32 1
   string "org.mozilla.firefox"
   string "video-playing"
method return time=1722263501.830515 sender=:1.31 -> destination=:1.6 serial=13664 reply_serial=9501
method call time=1722263501.830703 sender=:1.272 -> destination=org.freedesktop.DBus serial=339 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
   string "type='signal',sender='org.freedesktop.DBus',interface='org.freedesktop.DBus',member='NameOwnerChanged',arg0=':1.31',arg2=''"
method return time=1722263501.830924 sender=:1.272 -> destination=:1.31 serial=340 reply_serial=13663
   uint32 9
signal time=1722263501.830937 sender=:1.6 -> destination=:1.262 serial=9502 path=/org/freedesktop/portal/desktop/request/1_262/t/3738610708; interface=org.freedesktop.portal.Request; member=Response
   uint32 0
   array [
   ]

A possibly relevant merge request was started @ https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/305

Great investigation. It sounds like Bug 418433 is not helping here, and inhibited figuring out what was going wrong.

Git commit 1549c49f41f544cb9dad54de509f318cc5b6dc38 by Jakob Petsovits.
Committed on 30/07/2024 at 11:20.
Pushed by jpetso into branch 'master'.

Inhibit: Forward the correct inhibition flags to PolicyAgent

The Inhibit method ignored the value of the "flags" argument and
always sent InterruptSession as inhibition policy. This prevents
sleep, but does not prevent idle actions such as screen locking
and dimming.

This commit changes the requested inhibition policies to match
the documented values for "flags":

* Portals "Suspend" remains PolicyAgent "InterruptSession".
* Portals "Idle" becomes PolicyAgent "ChangeScreenSettings".
* Portals "Logout" and "User Switch" are not supported at this time
  and are merely logged but otherwise ignored.

PowerDevil, which implements the PolicyAgent API, uses the same
policies also to represent the logind "sleep" and "idle" inhibitors,
so we can trust that they behave accordingly.
Related: bug 472541, bug 335729

M  +12   -2    src/inhibit.cpp

https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/commit/1549c49f41f544cb9dad54de509f318cc5b6dc38

Git commit 8fd86c5b0e6d6797bff850947b07e086544cd617 by Jakob Petsovits.
Committed on 31/07/2024 at 10:37.
Pushed by jpetso into branch 'Plasma/6.1'.

Inhibit: Forward the correct inhibition flags to PolicyAgent

The Inhibit method ignored the value of the "flags" argument and
always sent InterruptSession as inhibition policy. This prevents
sleep, but does not prevent idle actions such as screen locking
and dimming.

This commit changes the requested inhibition policies to match
the documented values for "flags":

* Portals "Suspend" remains PolicyAgent "InterruptSession".
* Portals "Idle" becomes PolicyAgent "ChangeScreenSettings".
* Portals "Logout" and "User Switch" are not supported at this time
  and are merely logged but otherwise ignored.

PowerDevil, which implements the PolicyAgent API, uses the same
policies also to represent the logind "sleep" and "idle" inhibitors,
so we can trust that they behave accordingly.
Related: bug 472541, bug 335729


(cherry picked from commit 1549c49f41f544cb9dad54de509f318cc5b6dc38)

Co-authored-by: Jakob Petsovits <jpetso@petsovits.com>

M  +12   -2    src/inhibit.cpp

https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/commit/8fd86c5b0e6d6797bff850947b07e086544cd617

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

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

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

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