Page MenuHome GnuPG

Pinentry-gtk2 may fail to grab the keyboard
Closed, ResolvedPublic


(Moving the discussion in T3279 to its own issue.)

As reported by Robin H. Johnson on gnupg-devel:

I recently upgraded from pinentry 0.9.7 to pinentry 1.0.0, using the
gtk+-2 frontend, and was very surprised to have it break on me in a
strange way: the window would appear and disappear. It also still seemed
to be present in master (as of cd7b35e8ff)

I use a tiling WM, Awesome, so I've seen similar glitches in the past
for windows that wanted to steal focus.

Reproducable via:
$ pinentry-gtk-2 <<< "GETPIN"

  • (pinentry-gtk-2:10527): CRITICAL **: could not grab keyboard: not viewable (3)
  • (pinentry-gtk-2:10527): WARNING **: it took 4097 tries to grab the keyboard
  • (pinentry-gtk-2:10527): WARNING **: it took 233 tries to grab the pointer

Robin then identified the tooltip associated with the show/hide button as the likely source of the problem:

Some further digging within that commit, showed that if I commented out a
single line:

gtk_widget_set_tooltip_text (GTK_WIDGET(button), tooltip);

The issue reliably went away, as well and pinentry did NOT even need to retry
the grab.

I can reproduce Robin's observations (including the fact that disabling the tooltip solves the issue) on my system under Awesome, although in my case the number of tries needed to grab the keyboard never exceeds ~3000.

Possible solutions:

  • raise the max_tries limit further;
  • forget the tooltip for now;
  • something else?

Event Timeline

gouttegd created this object in space S1 Public.
werner triaged this task as Normal priority.Jul 25 2017, 3:48 PM
werner added a subscriber: werner.

I think disabling the tooltips for the gtk Pinentry is the way to go.

werner claimed this task.

Thanks for that. gpg-agent 2.1.23 or 2.2.0 will have a new default of --no-grab which can be reverted using the new --grab.