1587360 - Add support for idle-inhibit

Status: RESOLVED FIXED

(Core :: Widget: Gtk, enhancement, P3)

Description

[GreyXor]

idle-inhibit allows Wayland compositors to ignore screensaver (In the case of a full screen video for example)

Because the lack of support of idle-inhibit the videos played in full screen should allow Firefox to ignore the screensaver setting.

I can reproduce this issue in GTK and Sway Wayland compositors as well.

https://gitlab.freedesktop.org/wayland/wayland-protocols/tree/master/unstable/idle-inhibit

Comment 1

[GreyXor]

Blocks: wayland

Comment 2

[luis.pabon]

This would be immense, currently I need some hacky and brittle window rules in Sway to make sure system does not lock whenever I'm watching a vid full screen in FF.

Comment 3

[Val Packett]

Looking at the code, Firefox currently supports the org.freedesktop.ScreenSaver and org.gnome.SessionManager D-Bus interfaces for this, as well as XScreenSaver for X11.

GTK actually has its own gtk_application_inhibit function which currently only supports D-Bus (org.freedesktop.portal.Inhibit, org.gnome.SessionManager, org.xfce.Session.Manager). Might be worth using that in place of direct access to org.gnome.SessionManager, that would add Flatpak and XFCE support.

I'll try to add Wayland idle-inhibit now, seems easy enough.

Comment 4

[Val Packett]

( forgot to mention: I raised an issue in GTK for using idle-inhibit via gtk_application_inhibit https://gitlab.gnome.org/GNOME/gtk/issues/2202 )

Comment 5

[Val Packett]

Attachment: Bug 1587360 - Add support for idle-inhibit Wayland protocol

[WIP] The idle-inhibit protocol allows idle wake locks on Wayland
without any of the supported D-Bus interfaces running.

Comment 6

[Val Packett]

^^^

Turns out it's not completely trivial: unlike other ways of inhibiting idle, idle-inhibit-unstable-v1 requires a surface. Firefox's complex WakeLock infrastructure does not pass a window to where the protocol is invoked. Can someone experienced with that code help me make it do that?

(The current patch uses a terrible hack, but should work enough for testing in various compositors.)

Comment 7

[rpigott]

I started working on this recently and ended up with a very similar patch before I found this issue. Unfortunately, this is my first attempt hacking on firefox I was also stumped on how to find a suitable wl_surface reference to attach the inhibitor to.

I saw that there is nsWindow::GetWaylandSurface() which seems promising, but I couldn't find a relationship between the WakeLockListener and an nsWindow.

Does anyone know if the toplevel window is the only one that will need idle inhibition? I was leaning toward just finding a reference to that an grabbing its surface, but that also a pretty lousy hack.

Comment 8

[Martin Stránský [:stransky] (ni? me)]

I updated the phabricator review with an advice. Thanks for he patch!

Comment 9

[BugBot [:suhaib / :marco/ :calixte]]

There's a r+ patch which didn't land and no activity in this bug for 2 weeks.
:myfreeweb, could you have a look please?
For more information, please visit auto_nag documentation.

Comment 10

[Val Packett]

(In reply to Release mgmt bot [:sylvestre / :calixte / :marco for bugbug] from comment #9)
Haven't had any crashes related to this in these 2 weeks, so I guess let's go. Added Check-in Needed tag.

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/2a39a8e425b0
Add support for idle-inhibit Wayland protocol r=stransky

Comment 12

[Noemi Erli[:noemi_erli]]

https://hg.mozilla.org/mozilla-central/rev/2a39a8e425b0