Closed XRevan86 closed 7 years ago
I don't have this one installed at the moment, which means I would not see any behavioral changes other than either being unable to lock or unable to unlock the screen at all.
In a quick test installation, the screensaver panel applet could not lock the screen nor activate the screensaver. The preferences dialog worked. I have no idea however if this is ongoing or a result of this PR. Build was fine.
@lukefromdc, maybe you should have started the mate-screensaver daemon.
Starting mate-screensaver, then using the screensaver applet led to the screensaver being displayed for a few seconds, then crashing and returning to the desktop. Same if a new session was started with the screensaver daemon active. This really needs testing by someone who normally uses it and has it installed though,
EDIT: when started from terminal, no text went to the terminal when the screensaver closed after a few seconds
Erm, did we establish if this actually works? We may also need to branch this repo for 1.18, from before this commit, so we can cherry pick for a point release if required.
@flexiondotorg, this most definitely basically works %). Testing is still desired. Some freaky ways of trying to break the grab of mate-screensaver on the keyboard or something.
I meant to approve the merge, instead I just did it. But I have been testing it all day, and it appears to work just fine for me.
OK, good to hear ☺️
I see no regression here. Restarting the daemon after update and using the lock applet works out of box here. In a VM i restarted the session and locked the screen several times, no problems.
Hello,
this patch plus another bug makes this a security issue.
No
No
You're right. That code was buggy beforehand ;)
gdk_keyboard_grab
andgdk_pointer_grab
are removed from GTK+ 4 making this an important change for the future. Yet at the same time I can't be 100% confident because I'm touching (a lot) a very important part of screenlocking potentionally creating a "security issue".