Created attachment 9558 output of xfce4-power-manager --no-daemon --debug when random locks are occuring Starting after the update to xfce4-power-manager 1.6.6 certain events (opening file safe dialogs, media pop-outs) when using Chromium lead to the screen being locked falsely
Created attachment 9559 output of xfce4-screensaver --no-daemon --debug when random locks are occuring
I confirm this behavior
I confirm this behavior too, after updated to xfce4-power-manager 1.6.6 version
confirmed here as well. you can easily replicate (on least on my end) by launching discord. happens every other time discord is launched/
Confirmed here as well, a downgrade to 1.6.5-2 worked in my case.
Could anyone here test https://bugzilla.xfce.org/show_bug.cgi?id=16522 as well? It could be an issue caused by the same commit
(In reply to Maurizio Galli from comment #6) > Could anyone here test https://bugzilla.xfce.org/show_bug.cgi?id=16522 as > well? It could be an issue caused by the same commit Yes, I confirm - have the same situation. After I closed the lid of laptop and upping lid back - got similar message: - "none of the lock tools ran successfully, the screen will not be locked. Anyway use the standby mode?"
There is nothing really random about it. Every time a screensaver inhibition is removed, the screensaver activates. This can appear a bit random because many things can happen in a browser session that cause an inhibit to be activated and deactivated (like scrolling over video previews). To replicate, kill both xfce4-power-manager and xfce4-screensaver and fire both up, each in its own terminal window, with debug enabled: `xfce4-power-manager --no-daemon --debug`, same for `xfce4-screensaver`. In a Chromium browser session, google something that will have video results...try "how to disable screensaver." When the results show up, hover over one of the videos, which should begin to play its preview. Playing even the preview of the video causes Chromium to send out a screensaver inhibit signal: >TRACE[xfpm-inhibit.c:400] xfpm_inhibit_inhibit(): Inhibit send application name=/usr/lib/chromium/chromium reason=Video Wake Lock sender=:1.91 The power manager will show more lines related to the inhibit being added. At the same time, the screensaver will have heard these messages on Dbus: >[list_ref_entry] gs-listener-dbus.c:275 (09:44:57.655): inhibitor: xfce4-power-manager for reason: Inhibit requested As soon as the mouse moves off the video preview, Chromium sends an UnHibit (cute phrasing) message. And the screensaver immediately activates: >[listener_remove_ref_entry] gs-listener-dbus.c:598 (09:45:03.923): Removing inhibitor from xfce4-power-manager for reason 'Inhibit requested' on connection :1.97 >[listener_check_activation] gs-listener-dbus.c:308 (09:45:03.923): Checking for activation >[listener_check_activation] gs-listener-dbus.c:319 (09:45:03.923): Trying to activate >[gs_grab_grab_root] gs-grab-x11.c:347 (09:45:03.923): Grabbing the root window That's the bug right there: as soon as inhibition ends, screensaver activates, ignoring its own settings and timers.
(In reply to devonzh from comment #8) > That's the bug right there: as soon as inhibition ends, screensaver > activates, ignoring its own settings and timers. Pardon for the spam, but it looks like this bug has been fixed in xfce4-screensaver: https://git.xfce.org/apps/xfce4-screensaver/commit/?id=7e6fe76f548cd3e0ea1363e57f26aa9f3579fcfb Basically, upon de-inhibit, xfce4-screensaver didn't check whether the system had been idle and just activated the screensaver right away. That commit adds a single conditional which short circuits the activation if the system is not idle, as defined elsewhere. I can confirm that cherrypicking that commit fixes the issue of the screensaver seemingly randomly activating while browsing the web in Chromium (and very likely other browsers as well). Recommend this be closed.
Closed as suggested by devonzh.
*** Bug 16567 has been marked as a duplicate of this bug. ***