pinentry-gtk2 receives keystrokes even without focus

[Thomas Boje]

Binary package hint: pinentry-gtk2

If a pinentry dialog pops up, it takes all keystrokes. I can set the focus to another window - I use focus follows mouse - but cannot interact with the (now) focused window, because it does not receive any keyboard or mouse events. I can see text appearing in pinentry if I type something, though. I cannot even move any (!) window, although the window manager raises a window on title bar clicks. (I set it to do so).

I'm not sure whether this is a bug in my window manager (beryl; yes I know, unsupported and deprecated) or a bug in pinentry. But I think pinentry must at least request the window manager to misbehave in this way.

I suggest that either the pinentry window is globally modal, i.e. I just cannot set the (apparent) focus to another window or that it does not longer ignore other windows' focus. The latter might raise some security concerns, which could be why it behaves like this in the first place.

[Adam Niedling (krychek)]

What version of Ubuntu are you using? Is this still an issue?

[Thomas Boje (tb7653)]

By the time I posted it I'd guess that was with Ubuntu 7.10. This behaviour was still in 8.04. Meanwhile I switched to another distro (for other reasons) and it seems that this problem is not ubuntu specific.

Greetings,

   Thomas

[Adam Niedling (krychek)]

So you're not using Beryl anymore? It must be a pinentry issue then?

[Thomas Boje (tb7653)]

I use Compiz Fusion since quite some time now. And it is not really surprising, that it behaves the same way. (Compiz was forked into Beryl and later reunited with Compiz as Compiz Fusion.)

I just did a quick test with OpenBox. Normally gtkpinentry steals the keypresses there as well, but somehow I managed to get the input into a gvim window. It seems that gtkpinentry crashed on this, but I'm not sure what really happened.

Well it is gtkpinentry which must request focus in the first place. The window manager should then keep the visual focus ("active window" border) around the window receiving key strokes. On the other hand I personally think that it is a design error to provide programs a way to request this "feature" of catching *all* input independent of focus in the first place.

[Adam J Richardson (fatman-crackmonkey)]

I can confirm this on Jaunty using Ubuntu Netbook Remix and no Compiz.

Also, I found the pinentry window couldn't be moved or resized at all.

I was trying to add the pinentry window to maximus' exclusion list. It took me a while to work out how to get a console to execute "xprop | grep WM_CLASS" when I couldn't focus the console window. Eventually I pressed Ctrl-Alt-F2 and used "xprop -display :0.0 | grep WM_CLASS" to get the registered window class.

[Adam J Richardson (fatman-crackmonkey)]

This also happens in Metacity, so I think we can rule out a window manager bug.

[rusivi2 (rusivi2-deactivatedaccount)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. We are sorry that we do not always have the capacity to look at all reported bugs in a timely manner.
There have been many changes in Ubuntu since that time you reported the bug and your problem may have been fixed with some of the updates. It would help us a lot if you could test the current Ubuntu development version (10.10). If you can test it, and it is still an issue, we would appreciate if you could upload updated logs by running apport-collect <bug #>, and any other logs that are relevant for this particular issue.

[Adam J Richardson (fatman-crackmonkey)]

I can't comment on Maverick just yet, but I can confirm the problem is still present in Lucid LTS. I stopped using Netbook Remix a long while back because of other bugs.

[Todd A. Jacobs (codegnome)]

This isn't actually a bug. pinentry-gtk2 is *supposed* to grab the keyboard unless the --no-global-grab flag is passed. This is a security measure to prevent passwords from being typed into other windows by accident.

[Adam J Richardson (fatman-crackmonkey)]

I can see that point of view. That makes it a misuse of pinentry-gtk2 instead of a bug.

Suppose you have a situation where you might legitimately want to ignore the password dialog for a while. Maybe you use a KeePass database to store passwords, or you have an OS bug where you have to use a workaround to see dialogs. At best it means you have to cancel out, at worst it renders the system unusable.

I don't think these situations are unrealistic. I encountered them both myself. IMO pinentry-gtk2 should never be used in a desktop environment, because the user might actually want to ignore the dialog for a while without cancelling it.

[Adam J Richardson (fatman-crackmonkey)]

Sorry, I meant should never be used without --no-global-grab.

[Todd A. Jacobs (codegnome)]

I fully agree that the inability to use KeePassX, the clipboard, and so forth is a bug, but disagree that the default grab is a bug since it's working as designed. If you want to avoid grabs by default, then:

    echo no-grab >> ~/.gnupg/gpg-agent.conf

If this doesn't work for any reason, the bug would be in seahorse or gpg-agent, not in pinentry-gtk2.

I will mark this bug invalid, since it isn't actually a bug, but would encourage you to file a bug against pinentry-gtk2 about the inability to interoperate with KeePassX, as that is certainly a usability issue that is likely to surprise a great number of users.

[Adam J Richardson (fatman-crackmonkey)]

Thanks for the workaround. I'm fairly sure that would have fixed the original issue I was experiencing.

For other reasons, I have long since apt-get purge'd the package that was exhibiting the symptom. I'm not using UNR any more, as I dislike its tendency to expand all windows (*ALL* windows! including pinentry-gtk2 -- fugly) to the same size as the screen.