SUMMARY *** NOTE: If you are reporting a crash, please try to attach a backtrace with debug symbols. See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** After recent plasma's screensaver behavior changes, plasma now doesn't take into account screensaver inhibitors that come from non focused apps. This is a correct behavior, however, while screen dimming works in that case, automatic screen locking doesn't work. Some apps do dim screen inhibiting randomly (for example, steam) and this can lead to unexpected results, as the user may think that if the screen turns off and nothing interferes with it, then the system should be locked as specified in the settings, but because it doesn't trigger screen locking, unwanted persons can access the OS. STEPS TO REPRODUCE 1. Set both screen dimming and auto locking timeout to 1 minute 2. Open some video in a chromium (so it will inhibit screen dimming) 3. Minimize this window OBSERVED RESULT Screensaver works but after 1 minute OS is still unlocked EXPECTED RESULT Both screensaver and automatic screen locking works SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: Arch Linux (available in About System) KDE Plasma Version: 5.24.5 KDE Frameworks Version: 5.95.0 Qt Version: 5.15.4 ADDITIONAL INFORMATION Wayland/Xorg
Open the Battery & Brightness applet in your System Tray; what does it say about Chromium?
(In reply to Nate Graham from comment #1) > Open the Battery & Brightness applet in your System Tray; what does it say > about Chromium? "Chromium is currently blocking sleep and screen locking (playing audio)" (when minimized) This bug also occurs when lutris blocks sleep with "running game" message. Also, maybe it's little off topic, but in xorg firefox after minimizing removes it's inhibitor, but for wayland it doesn't. That's weird because wayland also sends minimize event? So it's probably either firefox wayland implementation bug or xwayland bug?
So yeah, it's doing what it says: blocking sleep and screen locking. Are you saying that something different happened in the past? If so, specifically what? What changed, and when?
(In reply to Nate Graham from comment #3) > So yeah, it's doing what it says: blocking sleep and screen locking. > > Are you saying that something different happened in the past? If so, > specifically what? What changed, and when? So it blocks sleep (system sleep or "suspend") and screen locking but not display sleeping? In the past (before plasma 5.24, it seems) I think it wouldn't trigger monitor sleep at all when there's any inhibitor that blocks somethings even with minimized window or locked screen.
I can't remember if inhibitions are universal, or an app gets to choose what to inhibit. Hopefully the Powerdevil developers can help some more.
(In reply to Nate Graham from comment #5) > I can't remember if inhibitions are universal, or an app gets to choose what > to inhibit. Hopefully the Powerdevil developers can help some more. Looks like I didn't understand the problem correctly. Lutris (which has the problem I described) uses Gtk.Application.inhibit with GTK_APPLICATION_INHIBIT_SUSPEND and GTK_APPLICATION_INHIBIT_IDLE flags. GTK_APPLICATION_INHIBIT_IDLE flag should inhibit both dim screen and lock screen (if I understood correctly from https://docs.gtk.org/gtk3/flags.ApplicationInhibitFlags.html) but powerdevil(?) interprets it as "disable lock screen but not dim screen" so it's probably powerdevil's regression. But it only work not intended when an app is not in focus. It's a bug anyway because it either should ignore inhibitors for minimized apps or respect them fully anywhere except lock screen. Blocking auto locking and not screen dimming is confusing.
(In reply to Artur Rudenko from comment #6) > (In reply to Nate Graham from comment #5) > > I can't remember if inhibitions are universal, or an app gets to choose what > > to inhibit. Hopefully the Powerdevil developers can help some more. > > Looks like I didn't understand the problem correctly. Lutris (which has the > problem I described) uses Gtk.Application.inhibit with > GTK_APPLICATION_INHIBIT_SUSPEND and GTK_APPLICATION_INHIBIT_IDLE flags. > GTK_APPLICATION_INHIBIT_IDLE flag should inhibit both dim screen and lock > screen (if I understood correctly from > https://docs.gtk.org/gtk3/flags.ApplicationInhibitFlags.html) but > powerdevil(?) interprets it as "disable lock screen but not dim screen" so > it's probably powerdevil's regression. But it only work not intended when an > app is not in focus. > > It's a bug anyway because it either should ignore inhibitors for minimized > apps or respect them fully anywhere except lock screen. Blocking auto > locking and not screen dimming is confusing. In addition, because of this bug, lutris now can't block screen dimming for games anymore.