Inhibit interface can silently fail

[randomdude999]

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 in dbus-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.

[YaLTeR]

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: flatpak/xdg-desktop-portal#1254

[YaLTeR]

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.

[TingPing]

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.

[YellowOnion]

Is there some way to get this prioritized, this bug is such a PITA.