8

I am trying to send keystrokes via xdotool. However, sending does not work properly.

Below is the log of a script that should select all the text in Gedit and copy it (but it does nothing instead), along with its output (captured by redirecting both stdout and stderr):

+ xdotool getwindowname 29360262
*Unsaved Document 1 - gedit
+ xdotool key --window 29360262 ctrl+a
+ sleep 1
+ xdotool key --window 29360262 ctrl+c
+ sleep 1

I have tried with Thunderbird, and the script does send the keys, but without modifiers (no Control, that is). By the way, in the script, keys are surrounded by ", like "ctrl+a".

The difference between Gedit and Thunderbird may be that Gedit is a GTK3 application, whilst Thunderbird seems a GTK2 application (but Firefox, which seems a GTK3 application, behaves like Thunderbird).

xdotool version 3.20141006.1
Operating System: Debian GNU/Linux 8.1 (Linux kernel 3.16.0-4-amd64)
Desktop Manager: GNOME Shell 3.14.4

  • 1
    if you use xbindkeys then you have to release the keys that trigger your script by xdotool keyup ... for reliable operation – grabantot Mar 10 '19 at 12:34
7

When a keyboard or mouse event is generated by an application rather than by an input peripheral, that event is marked as “synthetic”. Many applications reject synthetic events.

In theory, there is a security reason for that — you might run an application on your X display but under a different account or on a different machine — but X is so bad at isolating applications (it was never designed for that) that you shouldn't allow untrusted applications to access your display at all. And if you don't, then there's no reason to reject synthetic events.

As far as I know, Gtk doesn't offer a generic way to decide whether to allow synthetic events. It's up to individual applications, and I don't know what the default is if the programmer doesn't care.

There's another way to inject input events, with the XTEST extension. Events injected in this way appear exactly like events from an input peripheral: effectively, they come from a “test” input peripheral. The downside of this approach is that they're routed to a window in the same way as any other event, so they're sent to the window that has the focus (unless intercepted by the window manager). You can send XTEST events with (sufficiently recent versions of) xdotool, that's what it does if you don't pass a window ID.

xdotool windowactivate 29360262
xdotool key ctrl+a ctrl+c

Yes, that's annoying. You can find a discussion of this problem on the Selenium wiki. It seems that there's a way to send fake events to a GTK+ application via GTK signals or GDK events, but I don't know how that works.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.