Showing mouse cursor when Ctrl is pressed makes editboxes lose focus

[lhmouse]

Expected behaviour

Pressing Ctrl should not make editboxes lose focus.

Actual behaviour

This option, if enabled, may cause editboxes (such as when renaming a file in caja a.k.a. the File Browser) to lose focus when the Ctrl key is pressed (for example when people attempt to copy the name), making it impossible to copy the text without using a mouse.

Steps to reproduce the behaviour

1. Enable the option above. This launches msd-locate-pointer in the background. Starting this process manually can reveal the same issue.
2. Open a random directory with caja.
3. Select a file and press F2. This opens an editbox in place of the file name.
4. Press Ctrl. The editbox loses focus.

MATE general version

MATE 1.24.0

Package version

Package: mate-settings-daemon
Version: 1.24.0-1

Linux Distribution

Linux Mint 20 x86_64 MATE

Link to downstream report of your Distribution

N/A

[lukefromdc]

I just found that this did NOT occur(could not reproduce it) with mate-settings-daemon and caja from current (1.25) git master on 11-11-2020, running on Debian Unstable. Duplicated your exact test, and trhe edit box in caja retained focus

[lhmouse]

1. I cloned this repo on Linux Mint 20.

2. There were a lot of dependencies. I had to install them all.

   lh_mouse@lhmouse-ideapad ~/Desktop/mate-settings-daemon $ ./autogen.sh
   

3. There was no mate-desktop 1.25 on Linux Mint 20 (the latest version was 1.24) so I applied this to configure.ac:

   diff --git a/configure.ac b/configure.ac
   index cf4f72a..ffb03e5 100644
   --- a/configure.ac
   +++ b/configure.ac
   @@ -56,7 +56,7 @@ DBUS_GLIB_REQUIRED_VERSION=0.74
    GLIB_REQUIRED_VERSION=2.50.0
    GIO_REQUIRED_VERSION=2.50.0
    GTK_REQUIRED_VERSION=3.22.0
   -MATE_DESKTOP_REQUIRED_VERSION=1.25.0
   +MATE_DESKTOP_REQUIRED_VERSION=1.24.0
    LIBMATEKBD_REQUIRED_VERSION=1.17.0
    LIBNOTIFY_REQUIRED_VERSION=0.7.0
    LIBATSPI_REQUIRED_VERSION=2.0

4. Everything could be built normally with make -j8.

5. I started the program in question like this:

   lh_mouse@lhmouse-ideapad ~/Desktop/mate-settings-daemon $ ./plugins/mouse/msd-locate-pointer
   

   Pressing Ctrl activated the ripple effect around the mouse cursor so I suspected it worked.

   At least two distinct behaviors were observed:

   1. If I was renaming a file on the desktop, pressing Ctrl did not deactivate the edit box (expected).
   2. However, if I was renaming a file inside caja, the old behavior persisted.

   An additional side effect was observed:
   Normally, when an editbox gains focus, the fcitx-qimpanel tray icon should be a keyboard. But in the second case above, it became a penguin, suggesting nowhere was to enter characters. The original issue occurred no matter whether fcitx-qimpanel was running or not.

There might be divergences between Debian and Linux Mint. I am not clear about the details.

[lukefromdc]

I was testing in a caja navigation window. Different gtk or glib versions might also affect this (I have glib 2.67.0 (development version) and gtk 3.24.23 from ocal builds installed here

[lhmouse]

It looks like libglib2.0-bin is a bit out of date:

lh_mouse@lhmouse-ideapad ~ $ dpkg -l | egrep '\<lib(glib2\.0|gtk-3)-bin\>'
ii  libglib2.0-bin                             2.64.3-1~ubuntu20.04.1                      amd64        Programs for the GLib library
ii  libgtk-3-bin                               3.24.20-0ubuntu1                            amd64        programs for the GTK graphical user interface library

[lukefromdc]

Mint is slow to update a lot of things, your gtk version is reasonably recent though. For glib to affect this would be less likely (it's lower level code) but I would not rule it out. No doubt a LOT of other differences between ours setups of course.
I just checked to see if using compiz-reloaded and not marco was the difference(focus is issue here) but got the same behavior: renaming works as expected

[lhmouse]

I just tried Marco, Metacity and Compiz, all of which had the same issue.

Would it help if I provide a list of all packages?

[lukefromdc]

Wouldn't help me much, someone who can duplicate the problem will have to work on this.
One lead though is this: you and I just showed the window manager is NOT the problem, as changing WM does not change results for either of us.

[lhmouse]

This seems to be caused by XGrabKey => i3/i3#2843 (comment). I have no idea about how to resolve it, though.