Closed Bug 1587360 Opened 10 months ago Closed 7 months ago

Add support for idle-inhibit

Categories

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

71 Branch
All
Linux
enhancement

Tracking

()

RESOLVED FIXED
mozilla74
Tracking Status
firefox71 --- wontfix
firefox74 --- fixed

People

(Reporter: greyxor, Assigned: myfreeweb)

References

(Blocks 1 open bug, )

Details

Attachments

(1 file)

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

Blocks: wayland

Blocks: wayland
Type: defect → enhancement
Priority: -- → P3

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.

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.

( 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 )

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

^^^

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.)

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.

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

Assignee: nobody → greg

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.

Flags: needinfo?(greg)

(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.

Flags: needinfo?(greg)
Pushed by apavel@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/2a39a8e425b0
Add support for idle-inhibit Wayland protocol r=stransky
Status: UNCONFIRMED → RESOLVED
Closed: 7 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla74
You need to log in before you can comment on or make changes to this bug.