Open randomdude999 opened 10 months ago
Particularly, Firefox fails to inhibit idle in this fashion. It never reaches its Wayland inhibit-idle protocol fallback because the portal indicates success, even if there's no backend.
Moreover, if a backend exists and returns an error from Inhibit()
, that too seems to be silently ignored.
whether it's even possible to report errors from this interface
I think it's possible to return an error from any DBus call.
this can be worked around in other places (i.e. by adding
org.freedesktop.impl.portal.Inhibit=none
to portals.conf)
...which is currently also broken: https://github.com/flatpak/xdg-desktop-portal/issues/1254
Actually, it appears that there's currently no way at all to have xdg-desktop-portal to return an error from an Inhibit()
call. I've tried things like configuring an invalid impl for Inhibit, or even making my own impl for Inhibit and returning an error, the application always receives success from the Inhibit call. So fixing this issue in -gtk seems like it won't help at the moment.
Inhibit has a Request object and can set the results to failed there.
I looked into this and the code was just not structured to keep the Request around to set a result later, but I think it would work fine.
Is there some way to get this prioritized, this bug is such a PITA.
First of all, I'm not sure if this is a bug in the gtk portal or rather a design issue with the XDG portal API itself.
Currently, the Inhibit provider in src/inhibit.c tries to use
org.gnome.SessionManager
and, if that fails,org.freedesktop.ScreenSaver
. However, if the latter too fails, the provider will throw a warning, do nothing, and pretend to have succeeded (at least that's how it looks like indbus-monitor
). This gives no indication to application code that the inhibition didn't actually work, and prevents them from attempting fallback methods.I don't know enough about DBus or XDG desktop portals to know whether it's even possible to report errors from this interface. If it isn't, that's not too bad, as this can be worked around in other places (i.e. by adding
org.freedesktop.impl.portal.Inhibit=none
to portals.conf). But if it was possible to handle in x-d-p-gtk, that would be great.