autokey-gtk crashes when clipboard.get_clipboard() is invoked

[Wilhelm Peterßen]

Invoking clipboard.get_clipboard() - see the sample script below - causes autokey to hang.

text = clipboard.get_clipboard()
keyboard.send_keys(text)

ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: autokey-gtk 0.90.1-1.1
ProcVersionSignature: Ubuntu 3.5.0-17.28-generic 3.5.5
Uname: Linux 3.5.0-17-generic x86_64
ApportVersion: 2.6.1-0ubuntu6
Architecture: amd64
Date: Tue Nov 6 07:29:33 2012
InstallationDate: Installed on 2012-10-31 (5 days ago)
InstallationMedia: Ubuntu GNOME Remix 12.10 "Quantal Quetzal" - Beta amd64(20120926)
MarkForUpload: True
PackageArchitecture: all
ProcEnviron:
 LANGUAGE=en_US:en
 TERM=xterm
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: autokey
UpgradeStatus: No upgrade log present (probably fresh install)

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Lonnie Lee Best (launchpad-startport)]

I can confirm that this bug is also currently present in Ubuntu 13.04

Background:

I've created a simple python script so that AutoKey-GTK can alphabetize lines of selected text I select in a text editor (like gedit). The script is short and this is the entire script:

-------------------------------------------------------------------------

str = clipboard.get_selection()
ary = str.split('\n')
ary.sort()
str = '\n'.join(ary)
keyboard.send_keys(str)

-------------------------------------------------------------------------

Debugging:

I ran autokey-gtk in debug mode by typing this command in a terminal:
autokey-gtk -l

When I triggered the script, here's the output that was produced:

2013-10-07 16:48:39,105 DEBUG - service - Script runner executing: Script('Alphabetize Lines')
2013-10-07 16:48:39,105 ERROR - service - Script error
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/autokey/service.py", line 454, in execute
    exec script.code in scope
  File "<string>", line 1, in <module>
  File "/usr/lib/python2.7/dist-packages/autokey/scripting.py", line 820, in get_selection
    self.__execAsync(self.selection.request_text, self.__receive)
  File "/usr/lib/python2.7/dist-packages/autokey/scripting.py", line 865, in __execAsync
    callback(*args)
  File "/usr/lib/python2.7/dist-packages/gi/types.py", line 113, in function
    return info.invoke(*args, **kwargs)
TypeError: request_text() takes exactly 3 arguments (2 given)
Exception in thread Phrase-thread:
Traceback (most recent call last):
  File "/usr/lib/python2.7/threading.py", line 810, in __bootstrap_inner
    self.run()
  File "/usr/lib/python2.7/threading.py", line 763, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/usr/lib/python2.7/dist-packages/autokey/service.py", line 464, in execute
    self.app.notify_error(_("The script '%s' encountered an error") % script.description)
  File "/usr/lib/python2.7/dist-packages/autokey/gtkapp.py", line 239, in notify_error
    self.notifier.notify_error(message)
  File "/usr/lib/python2.7/dist-packages/autokey/gtkui/notifier.py", line 145, in notify_error
    self.show_notify(message, Gtk.STOCK_DIALOG_ERROR)
  File "/usr/lib/python2.7/dist-packages/autokey/gtkui/notifier.py", line 156, in show_notify
    Gdk.threads_enter()
NameError: global name 'Gdk' is not defined

[Larry (larry-redhat-bugs)]

Description of problem:
If autokey phrase is set to use paste using clipboard, it will hang. If the same phrase is attempted a second time, it seems that the input device becomes non-responsive and can only be resolved by switching to a virtual terminal (outside of GNOME) to kill the misbehaving autokey-gtk process.

Version-Release number of selected component (if applicable):
Name : autokey-gtk
Arch : noarch
Version : 0.90.4
Release : 4.fc20
Size : 438 k
Repo : installed
From repo : fedora

How reproducible:
Always

Steps to Reproduce:
1. Create a autokey phrase that uses Paste using Clipboard (Ctrl+V)
2. Type the phrase's abbreviation

Actual results:
Abbreviation is erased by no output appears.

Expected results:
Abbreviation is erased and phrase appears.

Additional info:
If multiple attempts are performed, the keyboard stops responding to key input and you are left with no keyboard input device. To resolve this, you must switch to a virtual terminal (Ctrl+Alt+F2) and perform a killall autokey-gtk as the user who started the autokey process.

This was also reported for Ubuntu in Launchpad - https://bugs.launchpad.net/ubuntu/+source/autokey/+bug/1075429

The root cause of this issue is identified by the following stack:

2014-04-21 11:47:09,832 DEBUG - interface - Sending string: u'some text that should be pasted\n'
ERROR:interface:Error in X event loop thread
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/autokey/interface.py", line 116, in __eventLoop
    method(*args)
  File "/usr/lib/python2.7/site-packages/autokey/interface.py", line 500, in __sendStringClipboard
    self.__fillClipboard(string)
  File "/usr/lib/python2.7/site-packages/autokey/interface.py", line 537, in __fillClipboard
    self.clipBoard.set_text(string.encode("utf-8"))
TypeError: set_text() takes exactly 3 arguments (2 given)

After this issue occurred, I had to terminate autokey which resulted in the following abrt report: https://retrace.fedoraproject.org/faf/reports/415062/

It is important to note that the abrt report wasn't actually triggered by the hang but instead by killing the process because it became unresponsive.

[Fedora (fedora-redhat-bugs)]

This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora 'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 20 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

[Christopher (christopher-redhat-bugs)]

*** Bug 1229371 has been marked as a duplicate of this bug. ***

[Christopher (christopher-redhat-bugs)]

This is still an issue in F22. The upstream issue hasn't been fixed for years. It would be great if this can be fixed in the Fedora RPM since the app itself works ok with the following patch:

$ cat autokey-gtk-rhbz1089695.patch
--- autokey-0.90.4/src/lib/interface.py 2012-05-15 07:27:57.000000000 -0400
+++ autokey-0.90.4/src/lib/interface-b.py 2015-06-08 10:49:04.269038660 -0400
@@ -534,7 +534,7 @@
             text = self.clipBoard.wait_for_text()
             self.__savedClipboard = ''
             if text is not None: self.__savedClipboard = text
- self.clipBoard.set_text(string.encode("utf-8"))
+ self.clipBoard.set_text(string.encode("utf-8"), len=-1)
             Gdk.threads_leave()

     def begin_send(self):

There's probably other areas where this should be fixed, but this patch fixed my immediate issue in BZ# 1229371.

I'm building a COPR with the package that includes the patch here:
https://copr.fedoraproject.org/coprs/cwawak/autokey

[Christopher (christopher-redhat-bugs)]

Created attachment 1036421
Patch to fix crash.

[Christopher (christopher-redhat-bugs)]

Bug still seems there in F23. What's needed to get this fixed?

[Fedora (fedora-redhat-bugs)]

This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora 'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 23 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

[Fedora (fedora-redhat-bugs)]

Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

[Larry (larry-redhat-bugs)]

This issue still affects Fedora 25.

----
2017-01-04 14:34:04,683 DEBUG - interface - Sending string: u'/*\n * Copyright (C) 2005-2014 Red Hat, Inc.\n * All rights reserved.\n *\n * This program is free software; you can redistribute it and/or modify\n * it under the terms of the GNU General Public License as published by\n * the Free Software Foundation version 2 of the License.\n *\n * This program is distributed in the hope that it will be useful,\n * but WITHOUT ANY WARRANTY; without even the implied warranty of\n * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the\n * GNU General Public License for more details.\n *\n * You should have received a copy of the GNU General Public License\n * along with this program; if not, write to the Free Software Foundation, Inc.,\n * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA\n */\n\n'
2017-01-04 14:34:04,685 ERROR - interface - Error in X event loop thread
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/autokey/interface.py", line 116, in __eventLoop
    method(*args)
  File "/usr/lib/python2.7/site-packages/autokey/interface.py", line 500, in __sendStringClipboard
    self.__fillClipboard(string)
  File "/usr/lib/python2.7/site-packages/autokey/interface.py", line 537, in __fillClipboard
    self.clipBoard.set_text(string.encode("utf-8"))
TypeError: Gtk.Clipboard.set_text() takes exactly 3 arguments (2 given)
----

This puts AutoKey into a bad state and upon next attempt to auto complete, the keyboard hangs.

The apparent fix was provided in attachment 1036421 and seems reasonable to me. Is this package no longer maintained? It looks like the upstream has not seen a release since 2012.

Additionally, someone has ported to Python 3. 0.93.7 contains this fix as well. Seems like it was introduced as part of the Python 3 port in https://github.com/autokey-py3/autokey/commit/7bbb17c634b65cbc417b1d56e862ea3f94a27b83. Problem is that the port appears to be missing the GTK specific launcher autokey-gtk.

If we can not get this fixed, I suggest that the package be removed as it can break GNOME if installed and clipboard feature is used.

[Thomas (tux12345)]

This issue is fixed in 0.95.9, which is part of Ubuntu 20.04

[Lonnie Lee Best (launchpad-startport)]

Fantastic!