Those settings are in the privacy panel, click on the 'Screen Lock' line. Even with automatic screen lock turned off there, the shield will come down when the user goes idle, though. There just won't ask your password, but bring you right back in your session when you lift it.


We should indeed make it so that hitting any key makes the shield go up. For me, that seems to be the case, though.

Observations on F19:

Moving the mouse wakes up the screen, but does not dismiss the shield.  Clicking does not dismiss the shield, although click-dragging the shield up does.  I was pretty sure XI2 had a way to distinguish mice from touchscreens, it doesn't make sense to force a touch gesture onto a mouse.  I guess I don't really care whether clicks dismiss the shield, but if drags work then clicks should too.

Modifiers wake up the screen, but dump you at the shield.  Keys with symbols  wake the screen and take you to the shell.  One habit I'd picked up was using Control or Shift to unblank the screen, _because_ they generate no symbol, thus ensuring I couldn't possibly type into some app (pressing the spacebar on a focused button is the same as clicking it, after all).  Since the shield is pretty useless when the display is not locked, it might make sense to treat modifiers like symbols in that case.

Otherwise this behaviour is annoying enough people that an extension was created:
https://extensions.gnome.org/extension/672/disable-screen-shield/

Unfortunately I suspect that it triggers crashes so I just disabled it on both my computers... I was used to moving the mouse to wake up the display and now i must press enter because of the screen shield. Moving the mouse was not a bad habit and it's annoying to be forced to change behaviour. I do understand the concern about touch-screen devices but I don't use GNOME on touch-screen devices.

also see: https://plus.google.com/104175436979387006170/posts/YqRPuk7eEhk

I elicited the code on which the screen shield disabling extension was based from a kind GNOME dev. Unfortunately, as observed above, it causes crashes, and the dev in question has not replied to a bug report.

Meanwhile, the screen shield continues to annoy. It makes sense to have something like this on a touch-screen device; it makes no sense on non-touch-screen devices. The ideal solution, therefore, would be to detect whether you're running on a touch-screen device, and only enable the screen shield if so; there is no need for a preference. People understand that their phones and tablets have shields of some sort; other than GNOME, I'm not aware of any other system that has tried to impose one on the desktop.

In the short term I'd settle for a (working) extension that gets rid of the shield, or even a patch to gnome-shell; unfortunately, hours of staring at the code got me nowhere: I eventually gave up and asked for help, which got us the unreliable extension. I'd be most grateful if someone who understands the code could help out.

I agree with the above comments.  The shield is nice for mobile users, but doesn't fit well with the desktop/portable UX.  If there were at least a dconf key/value to disable it that would be a fine start.

*** Bug 645782 has been marked as a duplicate of this bug. ***

I'm not sure touch/not-touch is even the appropriate distinction. For me the distinction is lock/not-lock.

on mobile, shield screens originated at a time when most people didn't lock their phones at all, so as long as the screen was on, sensitive information was visible and unintended interaction was possible.

on mobile, usually if you enable some form of lock screen, you don't *also* have a shield screen - the shield screens are, in design terms, really just lock screens with a very simple unlocking mechanism.

AFAICS the correct logic is this: show a shield screen when timed out if there is no form of locking enabled. Otherwise just show the lock screen when timed out, and put any widgets on that. There is no point to a shield screen 'in front of' a lock screen.

I would also like this. It seems like a common source of confusion and we see comments about it in the various Fedora support channels reasonably often.

Particularly, I notice that many people who have been using computers for a while do exactly as Adam Jackson suggests in comment #2 -- they hit shift or alt, because they traditionally wake the system with no (or at least, very little) risk of affecting underlying windows.

On my own system, I actually _have_ caused things to happen in windows below the lock screen because I've retrained myself to hit a letter instead. This hasn't caused any great harm, but it seems rather ironic.

*** Bug 734638 has been marked as a duplicate of this bug. ***

I've trained myself to hit [Esc] to dismiss the shield, and never observed that being passed to an underlying application. It's true though that for me the shield is merely an inconvenience and I'd disable it given the option.

The screen shield is really completely useless on a desktop when gdm locks the screen anyway... to login again after the session got locked the user is required to perform two actions: 

- first remove the shield 
- then unlock the session via entering the password at the gdm login screen 

I do not understand why it is such a big deal to say: well many people don't like it, here's your option to simply turn it off completely. 

thx , p.

Why has this been ignored completely for 4 years? Too busy?

(In reply to piedro.kulman from comment #11)
> The screen shield is really completely useless on a desktop when gdm locks
> the screen anyway... to login again after the session got locked the user is
> required to perform two actions: 
> 
> - first remove the shield 
> - then unlock the session via entering the password at the gdm login screen 

This is wrong, you can just start typing your password. You don't need to do anything to remove the shield except type the first character of your password.

(In reply to Michael Catanzaro from comment #13)
> This is wrong, you can just start typing your password. You don't need to do
> anything to remove the shield except type the first character of your
> password.

This is teaching users to do the wrong thing -- we shouldn't encourage people to type their password into *anything* but a system-provided password dialog box. One can easily imagine a scenario where typing blindly causes a password to get sent out over a public chat channel.

Second, it really is a usability problem, both for people new to the environment where it's unclear exactly what to do (just start typing is not particularly discoverable; anecdotally, I haven't seen anyone figure that out on their own but rather on getting the tip from someone) and for people who are as noted above used to moving the mouse or hitting a non-acting key (shift, ctrl, or alt) to clear a screensaver.

I'm not worried about "users don't like it" -- there are plenty of quirks with every operating environment that someone won't like. I don't think an option to disable is the right thing. Instead, I'd like to see a design which addresses the above two issues.

Well, Mathew, I like your way of thinking. 

First of all, I heard about "just start typing" before but to be honest I forgot and used the mouse to pull the shield up, which doesn't work correctly if you don't pull far enough (flips down again) - it feels not like a solid design as is at all. 

I get that it would be nice if the default settings are sufficient without needing an additional option to change it. But in this case there is already additional complexity in place: 

- you find yourself with a setting "disable screen locking" anyway but then again this is confusing because it DOESN't disable the shield but only the some other stuff as descibed above... 

- Also there is an additional setting for choosing not one but two background images - one for the desktop and one for the shield. In my case (don't know whether this is another bug?) the chosen image for the shield background doesn't show as the shield background which is used on the shield before you have to type in your password - it's the default one (and sometimes it just shows a white screen with shadowed white fonts... 

What I am trying to say here is: I think one clear option is way less confusing and intrusive: 

- turn it on (now showing the background option and show it consistently!) 
or
- turn it off (in this case do not bother the user with further settings as choosing a background for a shield he or she just chose not to use...)   



I'd also like to add that your comment "I don't care if users like it" is bothering me. It's perfectly alright to try to convince users of a better way of doing things but if they don't like it even after being presented with this way, - well, than it's just rude to force it on them. That's exactly the kind of attitude we blame Apple or Microsoft for.... 

Granted, if someone likes Gnome, they won't drop it for another DE just because of that one little nuisance (to be honest there is more things like that). But it makes their experience less enjoyable. I do not see the benefit unless you claim the Gnome dev team knows what is best for everyone. 

Making the shield the default and still adding the option as described in the above fashion does both: 

- present the vision to convince users of the vision while still giving those people that really don't like to cope with it still the option to actively get into the settings and switch it off. 

More happy users without giving up the vision - how can that ever be a bad? 

thx for reading, p.

sorry for the typo in your name....

(In reply to Michael Catanzaro from comment #13)
> (In reply to piedro.kulman from comment #11)
> > The screen shield is really completely useless on a desktop when gdm locks
> > the screen anyway... to login again after the session got locked the user is
> > required to perform two actions: 
> > 
> > - first remove the shield 
> > - then unlock the session via entering the password at the gdm login screen 
> 
> This is wrong, you can just start typing your password. You don't need to do
> anything to remove the shield except type the first character of your
> password.

This is just plain wrong. You should never expect a user to randomly start typing their password on a screensaver. 

On the desktop, this is one of the most annoying features of Gnome with no purpose and I cannot find any suitable solution to disable just this shield. There is no use-case for this swipe shield, it just generated more unnecessary clicks or mouse movements.

As a desktop/laptop user, I want to wake up my computer and be immediately presented with a login box to enter my password into. Alternatively, if the screensaver has been activated just return to the desktop no further swipes or clicks.

Please fix this.

I am really confused about the way this bug tracker should work... 

On every bug here there seems to always be someone to very quickly point out every little inconsistency, every little misinterpretation or misnaming in any form of critic - "this is wrong - you can just type your password..." 

Still we are missing any constructive comment for more than 4 years now. 

Micheal Cantanzaro, why don't you step up here and discuss the issues involved here instead of pointing out imprecisions in other's comments.    

Please explain to us: 
- whether you are still working on this or is it abandoned?  
- why you think the design is good the way it is or how we can change it? 
- why constructive points like my suggestions of adding a system settings are entirely ignored (you want user bug reports, do you?) 

Thx, p.

(In reply to piedro.kulman from comment #18)
> Please explain to us: 
> - whether you are still working on this or is it abandoned?  

I'm definitely not working on this, sorry. My only participation so far in this bug report was to point out that comment #11 was wrong.

> - why you think the design is good the way it is or how we can change it? 

I've used it for many years without any problems, so changing it is not going to be on my own TODO list. But I understand it can be pretty confusing for new users. Endless has disabled it entirely for this reason.

I also disagree that typing your password when the screen shield is visible is generally somehow dangerous: the input can only ever go into the lock entry, which is usually perfectly safe. But it *could* be a problem if you configure your screen to turn off before it locks. Maybe screen shield should not appear at all in that scenario? I don't know.

> - why constructive points like my suggestions of adding a system settings
> are entirely ignored (you want user bug reports, do you?) 

Because there's 2034 other GNOME Shell bugs here. :) Bugzilla is pretty good for tracking bugs, but getting replies is best-effort.

Since you asked, I personally think we should add a setting for this, since many people who like GNOME clearly want to be able to turn it off, and that would be a quick and easy solution. But I'm not one of the GNOME Shell maintainers. And GNOME developers and designers are generally skeptical of preferences, for good reason: see http://ometer.com/preferences.html. There is also an argument that, if a setting is needed here, that means the default behavior is not good enough.

Thx a lot, Michael, for your clarifications! 

And for the link. Now I see more clearly where the notorious gnome attitude stems from and is defended so fiercely. 

But though I see many valid points in there -  it's not 2002 anymore (the articles original date)! We haven't had mobile devices for different kinds of use cases, different workflows and form factors. 

A desktop shield on a phone might be useful to the same person who considers the same shield an annoyance on the desktop. How can this be decided by a developer (even if he or she is willing to engage in the discussion and to take the heat from users as the article suggests...)? 

But there is one fundamental, even naive flaw in the idea of "good" and "bad" user interface design: 

The terms "good" or "bad" are terms describing intentional contents. People have intentions. Functionality doesn't.

Something supporting somebody's intentions is "good" (for him), something hindering reaching his goals or intended workflow is "bad". Functionality can never be good or bad in itself - either it serves the intentions of the user using it or it doesn't. 

To claim (I am not saying you do!) the default behaviour is good (or bad for that matter) makes the dubious assumption that every user has at least roughly the same intended way of using it. Otherwise there is no valid argument. 

This premise ("every user has the same intended workflow using gnome shell") is obviously very unlikely. And it's disrespectful cause it defies the uniqueness of each user and his intended way of doing things. There can't and should not be such a thing as per se "good" defaults. 

Popular defaults, sure, uncontroversial defaults, also plausible but a "right" way of using just about anything is technocratic nonsense.    

This might be different for purely technical matters where intentions are defined beforehand. Something like: "We have to improve the realtime response speed of the kernels subprocess XY..." might not be subjective at all...  

User interaction means by definition that user's intentionalities are involved - there is no clear technical achievement to be had here. Only satisfied or unsatisfied users...  

Unless of course the developers are talking about their very own intentions of how they think people should mandatorily use their stuff. 

I hope that's not the case with gnome developers. Maybe it would be useful to the discussion if developers here and there spent some time looking into social science and social reasoning as well... otherwise they might end up as technocrats. Nobody wants that!  

If user's flavors, habits and intended workflows don't matter for what the gnome team considers "good" or "bad" why even have a discussion about it? That's a waste of all our time then (which is precious if there's over 2000 more bugs  open... and also the opposite of what the linked article suggests!). 

It's fairly simple: 
Settings are useful because people use tools like desktops in different ways. And they do it in different scenarios and on different devices. 

Also settings show respect for the diversity of use cases and workflows. 
A "one fits all" nowadays is disrespectful in more than one way...  why choice is supposed to be good for linux, opensource and users (or consumers) in general but is feared by gnome is beyond me... 

To be clear I am not trying to offend you - as I said (and I mean it): 
Thanks a lot for your explanations and your opinions. I really like an open discussion about problems of usability and how to solve them. 

It's just frustrating commenting on bugs or usability issues when the people responsible, the people who can fix it don't even show up... (btw: the opposite of what the article suggests!)

There you have it - that's my two cents. 

And also I still ask the gnome shell team to consider an option in the settings: 
- I am on mobile, I want to use the desktop shield  
- I am on classical desktop, I do not need the desktop shield 

There is an option to disable wireless LAN (flight mode), where is the problem with an option to disable the shield, "standalone desktop mode" for example... 

Best regards, P.

I still see this problem in users who are new to Fedora / GNOME. I'd prefer to see a unified screen with the password dialog and any notifications.

But, if designers are still sure that the separate screens are conceptually important, could someone look at the "Lift shield after a 2nd press regardless of key" patch at https://bugzilla.gnome.org/show_bug.cgi?id=722113#c9? I think this would address a lot of the usability issue.

(In reply to Matthew Miller from comment #21)
> I'd prefer to see a unified screen with the password dialog and any 
> notifications.

That's something currently being worked on on the design side[0], but there's no finalized design or any implementation work yet.

[0] https://gitlab.gnome.org/GNOME-Community/design-team/london-ux2017-experiments/tree/master/lock-login

I came across bug #720656, which seems strongly related to this....

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.

Moved to https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4446