GNOME Bugzilla – Bug 722113
screenShield: Unconditionally lift the shield on any key press
Last modified: 2021-07-05 14:29:56 UTC
See https://lists.fedoraproject.org/pipermail/desktop/2014-January/008636.html Any reason we're not doing this already? I admit I also find the current behavior slightly frustrating.
Created attachment 266171 [details] [review] screenShield: Unconditionally lift the shield on any key press
Review of attachment 266171 [details] [review]: I think the idea is that you can hit Control or something to see the shield, which shows you your notifications. But I agree the design hasn't really worked out in practice. It doesn't make sense to have a shield if it will be raised on literally everything, though.
Most keys raise the shield; some don't - comment 2 explains why. What's the problem exactly?
The problem is admittedly habit. Hitting a modifier to wake up the screen "without side effects". Some people expect to see a password prompt at that point. In any case, IIUC the rationale for the current behavior is that we want a way to wake up the screen from DPMS but still want to show the shield because of the notifications. In that case what about doing the following: if (have notifications) keep current behavior else raise the shield on any key press ?
(In reply to comment #3) > Most keys raise the shield; some don't - comment 2 explains why. What's the > problem exactly? Here's a quote from the fedora-desktop list: I tested this in F20, and it is still unresponsibe to Shift, Ctrl, or Alt. This causes a particularly ironic problem, since many of us learned that these are the keys that should always be used to clear a screensaver, because anything else might inadvertently get passed through to an application "below". (And honestly, I think that's still good advice that the currently design undermines.) Of course that last point doesn't really make any sense, since the shield prevents that very issue. But anyway, this has come up on the mailing lists a couple of times before. In this case, it's in response to a user who thought that mouse movement was mandatory to raise the shield. It seems completely incredible, but another user in the same situation wrote to one of those lists a couple of months ago, who tried to use modifier keys to raise the shield and didn't think to try other keys when the modifier keys didn't work. So I dunno.... (And then there's mails like [2], which is unfortunately representative of another class of complaints on the lists, but that's only tangentially-related.) To be clear, I'm not arguing in favor of this change, just answering the question. It's a complete non-issue once you understand how the shield behaves. [1] https://lists.fedoraproject.org/pipermail/desktop/2014-January/008636.html [2] https://lists.fedoraproject.org/pipermail/desktop/2014-January/008632.html
> if (have notifications) > keep current behavior > else > raise the shield on any key press Will it be obvious that you're not seeing the screen because you don't have notifications, or will people think that the shield only is raised sometimes but not other? IMHO, there is a difference between **thinking** you didn't miss any notifications (because the shield was raised, so that must be what it meant, right?) and **knowing** it. (because the shield actually displayed no notifications) Alternatively, one can also wiggle the mouse to wake up the screen without raising the shield. So maybe any keyboard activity should completely raise the screen, and those of us who want to wake up the screen without raising the shield automatically (I am very much in this case) can move from the shift key to the mouse? I wouldn't really mind personally, as long as there is a way (any quick way) to wake up the screen without raising the shield.
I spent a chunk of time trying to work out how we could modify the behaviour of the shield depending on whether there are notifications, and I discussed it with Jon and Jakub today on #gnome-design. The problem is that adjusting the behaviour based on whether there are notifications makes it unpredictable - it doesn't feel nice to expect one thing to happen, but to get something else. Also, we probably want to retain the ability to check for notifications without throwing the user to the login screen.
I always found it weird that from a blank screen I could type my password and press enter -- meaning that the first character wakes the screen, raises the shield, and is entered as the first character in the password box. What I always expect is for the first character to wake up the screen (& show the shield) and the second character to raise the shield and be entered as the first character in the password box.
Created attachment 283504 [details] [review] screenShield: Lift shield after a 2nd press regardless of key -- This is another alternative. I've been running with it for a long while and it addresses my instinct since I usually press Ctrl or Shift several times to wake up the screen.
(In reply to comment #5) > I tested this in F20, and it is still > unresponsibe to Shift, Ctrl, or Alt. This causes a particularly ironic > problem, since many of us learned that these are the keys that should always > be used to clear a screensaver, because anything else might inadvertently > get passed through to an application "below". (And honestly, I think that's > still good advice that the currently design undermines.) > > Of course that last point doesn't really make any sense, since the shield > prevents that very issue. FWIW, consider the case where the computer is slow -- either a low performance system, or one which is overloaded. It's easy to be impatient and hit a key a number of times hoping for a response. If a password is required, that will of course absorb the keystrokes, but not, it's easy for them to go on to underlying applications.
I use the shield without a password lock. I've given the current behaviour several months but I have not adjusted yet and still find it counter-intuitive. Consider two scenarios: A) 1) Return to desk. 2) Press "enter" 3) wait few seconds for external screen to wait from DPMS. 4) start working. B) 1) Return to desk. 2) Press shift. 3) wait few seconds for DPMS. 4) screen shield still in place. 5) In theory press "enter", but in practice I think "silly screen saver, must remember to file papercut bug" and REACH FOR THE MOUSE. I've done B) daily for months and still not adjusted my behaviour. If I'd just mashed my hands on the keyboard, it would have unlocked and passed most of those keys to an application. (In other words, my shift choice is the rational key to press for the traditional reason, but I'm punished for using that). Finally, while the screen is fading to black but before DPMS there is an inconsistency: shift will still unlock. This further trains me that shift is the "right choice". (Note: pressing enter during fade to black DOES NOT pass to application which is consistent with the shield behaviour: nothing wrong there) I feel like the shift-ctrl-to-check-msgs design assumes instant DPMS wake which is unfortunately not the case, at least with external screens.
Comment #2 explains why we're not going to make Shift raise the screen shield. Rui's patch in comment #9 might be a good idea. Can someone review that? Otherwise I think it's time to WONTFIX this bug.
comment #9 does seem like it will help with some of the user confusion. How about making all keys lift the shield in the case where notifications on the lock screen are disabled?
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ Thank you for your understanding and your help.