After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 692937 - Gnome shell prompt automatically completes
Gnome shell prompt automatically completes
Status: RESOLVED FIXED
Product: gnome-shell
Classification: Core
Component: general
3.6.x
Other Linux
: Normal major
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
: 690592 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2013-01-31 12:29 UTC by Martyn Russell
Modified: 2020-11-15 07:10 UTC
See Also:
GNOME target: 3.8
GNOME version: ---


Attachments
modalDialog: Fix auto-completion of prompts immediately upon display (1.83 KB, patch)
2013-02-13 21:00 UTC, Stef Walter
committed Details | Review
Rebased patch for version 3.6.3 (1.78 KB, patch)
2013-02-24 13:37 UTC, Atri
reviewed Details | Review

Description Martyn Russell 2013-01-31 12:29:47 UTC
So, Emacs has this nice feature which Tim Janik posted about on G+ here:

  https://plus.google.com/u/0/110781595661917803096/posts/SuWskgkJqRL

I've been using it to store passwords - bit better than clear text obviously. :)

It works fine for *opening* files, but not for *saving*.

I have to unset GPG_AGENT_INFO before starting Emacs to use the Emacs built in save file with password/verify password functionality to make any changes.

Quite easy to reproduce.

1. $ emacs foo.gpg

2. Write some content

3. Save the file

4. Enter password first time when prompted (by GNOME shell dialog)

You should see an error in the Emacs window that it couldn't save the file. The Emacs messages window says:

"""
Saving file /home/martyn/foo.gpg...
stdin: 0% (0/0)
byte-code: Opening output file: Encrypt failed: ((exit))
"""

--

What's expected to happen is, a second password request comes up to *verify* the password and then the file is saved if the passwords match.
Comment 1 Stef Walter 2013-02-12 05:50:17 UTC
Do you see a second prompt come up quickly and flicker away? You can try to reproduce this simply by doing:

$ gpg --encrypt --symmetric
Comment 2 Martyn Russell 2013-02-12 08:48:22 UTC
When testing today, even the first prompt didn't show properly. It flashes up and disappears before I can enter anything. This is all from Emacs. There is no way to specify the gpg command line AFAICS.

If I try gpg --encrypt --symmetric foo.gpg or even without the foo.gpg, it does the exact same thing. The GNOME dialog flashes up once but doesn't give me a chance to insert any text.

So it does look like the same behaviour using your command line there yes.
Comment 3 Stef Walter 2013-02-13 20:55:13 UTC
So this is due to gnome-shell prompts automatically completing. Here's what happens. The shell prompt listens to a key-release-event in order to complete its default action. 

If the user pressed <enter> as the last action before a prompt is displayed, then the key-release-event of that <enter> key press completes the shell prompt.

In the case of emacs and gpg, two prompts are being displayed, an initial passphrase prompt and a confirmation prompt. The second one is catching the key-release-event of pressing enter on the first one. Pretty wild.

You can see that if you're not pressing enter at the exact time a prompt is displayed (ie: use the mouse, or in the case of a shell command: sleep 1; my command), then everything works as expected.

I thought there was another bug for this that I filed about polkit prompts doing the same thing... But I can't find it now, so let's use this one.
Comment 4 Stef Walter 2013-02-13 21:00:07 UTC
Created attachment 235954 [details] [review]
modalDialog: Fix auto-completion of prompts immediately upon display

Shell modal dialogs can take their action on a certain key's
key-release-event. For example on <enter> the affirmative action is
usually run.

Make sure that the key was also pressed on the dialog and we're not
seeing a spurious key-release-event from a key that was pressed before
the dialog was displayed.

This patch needs testing. Will do once jhbuild gets that far.
Comment 5 Stef Walter 2013-02-13 22:30:30 UTC
Tested. The patch fixes the problem for me.
Comment 6 Atri 2013-02-24 04:41:55 UTC
Hi! I am using gnome-shell 3.6.3 and am also hit by this bug; would it be possible to have a similar patch for version 3.6.3 as well? That would be very much appreciated.

Thanks!
Comment 7 Atri 2013-02-24 07:23:12 UTC
Hi! I tired to rebase the above patch to version 3.6.3. Please let me know if this is the correct way to do this:-

Index: gnome-shell-3.6.3/js/ui/modalDialog.js
===================================================================
--- gnome-shell-3.6.3.orig/js/ui/modalDialog.js
+++ gnome-shell-3.6.3/js/ui/modalDialog.js
@@ -57,8 +57,10 @@ const ModalDialog = new Lang.Class({
 
         this._group.connect('destroy', Lang.bind(this, this._onGroupDestroy));
 
-        this._actionKeys = {};
-        this._group.connect('key-release-event', Lang.bind(this, this._onKeyReleaseEvent));
+        this._pressedKey = null;
+        this._actionKeys = {};
+        this._group.connect('key-press-event', Lang.bind(this, this._onKeyPressEvent));
+        this._group.connect('key-release-event', Lang.bind(this, this._onKeyReleaseEvent));
 
         this._backgroundBin = new St.Bin();
         this._monitorConstraint = new Layout.MonitorConstraint();
@@ -186,10 +188,19 @@ const ModalDialog = new Lang.Class({
 
     },
 
+    _onKeyPressEvent: function(object, event) {
+        this._pressedKey = event.get_key_symbol();
+    },
+
     _onKeyReleaseEvent: function(object, event) {
+        let pressedKey = this._pressedKey;
+        this._pressedKey = null;
+
         let symbol = event.get_key_symbol();
+        if (symbol != pressedKey)
+            return false;
+ 
         let action = this._actionKeys[symbol];
-
         if (action) {
             action();
             return true;
Comment 8 Atri 2013-02-24 07:30:39 UTC
Tested rebased patch on my system (with gnome-shell 3.6.3), seems to fix the problem.
Comment 9 Stef Walter 2013-02-24 10:14:01 UTC
Atri. Thanks for doing that. I didn't test the GNOME 3.6 patch, but it does indeed look right. 

I would suggest attaching the rebased patch with a proper commit message to this bug. There do seem to be several needless whitespace changes that would be easier to spot when attached.
Comment 10 Atri 2013-02-24 13:37:37 UTC
Created attachment 237272 [details] [review]
Rebased patch for version 3.6.3

Attached rebased patch for gnome-shell-3.6.3 for review. Thanks!
Comment 11 Atri 2013-02-27 20:12:39 UTC
Hi Stef!
Could you please review the rebased patch for 3.6.3 attached with comment 10 above? Thanks!
Comment 12 Jasper St. Pierre (not reading bugmail) 2013-03-03 21:08:15 UTC
Review of attachment 235954 [details] [review]:

I had a similar patch before finding you already did this. OK.
Comment 13 Stef Walter 2013-03-04 08:38:54 UTC
Attachment 235954 [details] pushed as 7b705dd - modalDialog: Fix auto-completion of prompts immediately upon display
Comment 14 Stef Walter 2013-03-04 08:43:10 UTC
Comment on attachment 237272 [details] [review]
Rebased patch for version 3.6.3

Looks good.

Although it's probably Jasper's call whether this goes in the gnome-3-6 branch.
Comment 15 Florian Müllner 2013-03-04 08:47:35 UTC
It is unclear whether there will be another 3.6.x release, but assuming that the patch has been tested, I'm fine with it being pushed to the gnome-3-6 branch.
Comment 16 Stef Walter 2013-03-04 08:59:43 UTC
Pushed to gnome-3-6 branch. Have been running this with gnome-shell 3.6.3
and it does the trick.
Comment 17 Atri 2013-03-04 21:49:54 UTC
(In reply to comment #16)
> Pushed to gnome-3-6 branch. Have been running this with gnome-shell 3.6.3
> and it does the trick.

Thanks, Stef, for the review and the push to gnome-3-6 branch.
Comment 18 Ray Strode [halfline] 2013-03-04 22:02:01 UTC
this patch may be causing issues. see bug 695154
Comment 19 S. 2013-10-08 04:40:37 UTC
On Gnome 3.8.4 I frequently run into problems with the Gnome Shell password prompt. It repeatedly rejects my password, but then after a while it starts accepting it. It is very random and hard to pin down. Sometimes it rejects the first time and accepts it the second time. Sometimes on the third time. Occasionally it works on the first try. Sometimes it just keeps rejecting it. (Yes, I am typing my password correctly.) I usually open programs by searching applications menu and hitting enter, if that makes any difference.
Comment 20 mr.fies 2014-01-15 20:52:59 UTC
Hello, I think I have this problem when trying to start gparted. But I am new to Linux and dont know how to apply that patch. I am using gnome-shell 3.6.3.1 ( I think ;)  )
Can someone help?
Comment 21 André Klapper 2020-11-15 07:10:51 UTC
*** Bug 690592 has been marked as a duplicate of this bug. ***