GNOME Bugzilla – Bug 758873
bad choice of default behaviour reveals password in login screen
Last modified: 2017-08-23 18:55:20 UTC
On a slow computer it is enough to press enter three times after entering the password to reveal it (eg. because one is impatient?). Even on modern hardware this can happen with slightly misspelled passwords because of the 3 (?) seconds default sleep upon entering a wrong password. This is due to a bad choice of default actions. When the password is already entered another press of the enter key opens the menu with the "show password" option marked as default action, so pressing enter again in fact does reveal the password. I am currently on 3.18.2 but this behavior is not new...
When the sign-in button is pressed, we should disable the context menu.
I have been running into this recently (without knowing why my password is showing). It was pretty alarming. I would greatly appreciate if this behavior was changed.
Created attachment 348699 [details] [review] popupMenu: Don't handle key events for insensitive source Generalizing menu toggling via keyboard in commit 1d58ea25ab6f047 fixed keynav in many places, but it turns out that it also adds unexpected interactions in some cases where the source is not button-like, as for example the entry context menus provided by ShellEntry. Commit e33c68a415 fixed one case, however it is still possible for plain enter/space to unexpectedly trigger the menu if the entry itself doesn't consume the event, which is the case when ClutterText:editable is false. However for a general fix, it makes more sense to consider the source actor's :reactive property and disable toggling menus via keyboard when they cannot be toggled by pointer either - expecting non-editable entries to be non-reactive as well seems like a reasonable assumption, and indeed all our code follows that pattern.
Another less-general fix would be to override the _onKeyPress() handler in EntryMenu with a no-op to make sure that the menu is only brought up via the ::popup-menu signal.
Review of attachment 348699 [details] [review]: This makes sense to me. another idea would be to connect to notify::reactive on the source actor and call setSensitive or something like that.
Attachment 348699 [details] pushed as 647c8df - popupMenu: Don't handle key events for insensitive source (In reply to Ray Strode [halfline] from comment #5) > This makes sense to me. another idea would be to connect to > notify::reactive on the source actor and call setSensitive or something like > that. This sounds like a good option for making the menu insensitive (although I suspect it will still pop up?), but setting it automatically to sensitive again when the source becomes reactive may interfere with explicitly set sensitivity, so I'm a bit wary here. I'll go with my original patch ...
*** Bug 786686 has been marked as a duplicate of this bug. ***