GNOME Bugzilla – Bug 740043
password frequently gets shown when unlocking screen
Last modified: 2016-11-07 19:02:10 UTC
I recently changed my password to one that ends with a symbol. I'm kind of a sloppy typist and will often hold down shift a little too long after typing the symbol. Shift-Enter brings up the context menu with one available option "Show Text". For some reason, a fair percentage of the time I end up hitting Enter a second time and showing my password. Not sure what the right answer is. A few ideas: a) maybe we should use shift-f10 instead of shift-enter to bring up the context menu? b) maybe we should require arrowing down once the menu is shown c) maybe i should change my password to not end in a symbol d) maybe i should be less sloppy when i type
(In reply to comment #0) > Not sure what the right answer is. A few ideas: > > a) maybe we should use shift-f10 instead of shift-enter to bring up the context > menu? It's actually supposed to be shift-f10[0] - no idea where shift-enter comes from, but I can indeed reproduce the issue (also with the search entry)... [0] https://git.gnome.org/browse/gnome-shell/tree//src/st/st-widget.c#n741
*** Bug 773465 has been marked as a duplicate of this bug. ***
Curiously, I can get Shift-Enter to act as the Menu key in the following places - login screen password entry - looking glass expression entry but it acts as a regular Enter key in the following places: - overview search box - Alt-F2 run dialog entry box
Found it! Shift-Enter (and also Alt-Enter/Ctrl-Enter) causes this bit of JavaScript in PopupMenu._onKeyPress() to call this.toggle(), which shows the popup menu: https://git.gnome.org/browse/gnome-shell/tree/js/ui/popupMenu.js#n787
oh great, thanks for looking into it
Created attachment 338530 [details] [review] popupMenu: don't handle key presses directly if there are modifiers commit 1d58ea25ab6f0472bdeffc9170ece37d5dd71e64 changed the popupMenu code to handle key presses on source actors directly. This fixed keynav into the session gear menu at the login screen. Unfortunately, it also causes spurious pop ups if a modifier happens to be held down. This commit checks for modifiers and short circuits the up front key handling if any are found.
Marius do you mind trying the (as of yet) untested patch in attachment 338530 [details] [review] ?
Review of attachment 338530 [details] [review]: ::: js/ui/popupMenu.js @@ -786,0 +786,6 @@ + let state = event.get_state(); + + // if user has a modifier down (except capslock) ... 3 more ... Shouldn't this be state &= ~Clutter.ModifierType.LOCK_MASK; ?
(In reply to Marius Gedminas from comment #8) > Shouldn't this be > > state &= ~Clutter.ModifierType.LOCK_MASK; Yes! :-)
Created attachment 338538 [details] [review] popupMenu: don't handle key presses directly if there are modifiers commit 1d58ea25ab6f0472bdeffc9170ece37d5dd71e64 changed the popupMenu code to handle key presses on source actors directly. This fixed keynav into the session gear menu at the login screen. Unfortunately, it also causes spurious pop ups if a modifier happens to be held down. This commit checks for modifiers and short circuits the up front key handling if any are found.
(still untested)
I've tested the updated patch (with jhbuilt gnome-shell in the 3.22 branch). It works fine (by which I mean Shift-Enter in looking glass and the lock screen doesn't open the popup menu, it acts as a regular Enter).
Review of attachment 338538 [details] [review]: OK
*** Bug 774040 has been marked as a duplicate of this bug. ***
Attachment 338538 [details] pushed as e33c68a - popupMenu: don't handle key presses directly if there are modifiers