Mouse pointer gets stuck to "move" cursor

In Thunar, whenever I scroll a through a large list of files (where a scrollbar is available to the right of the window) using the touchpad (with two fingers scroll/side scroll) the mouse pointer gets stuck at the "move" cursor and does not change back to the normal arrow pointer until the mouse is moved to some other pane/window. The problem is not there with other applications such as Mousepad in which the pointer turns to "move" when I touch the touchpad with two fingers but swiftly reverts to the text input cursor the moment I remove one of the fingers.

My specs are:

Dell Inspiron 13 5000 series

Manjaro Linux 20.1.1

Kernel: 5.8.11-1

Bus 008 Device 004: ID 06cb:7e7e Dell Touchpad

changed the description

changed the description

added 5. Scrolling label

Does this happen in all Thunar views or only when using the detailed list view?

This happens only in the detailed list view.

Thanks.

added 5. List View (Detailed View) label

Would you be able to test with a different file manager (Nemo or Caja)?

I tested for the problem in both Nemo and Caja (in all the three views: Icon, List and Compact) and there is no problem in both these file managers i.e. the pointer swiftly changes to arrow the moment I remove one finger.

Interestingly enough (at least to the maintainers to Nemo), the problem appears in Nemo's Edit>Preferences>Plugins>Actions pane. I scroll up/down five or six times and sometimes, the pointer freezes to the "move" cursor...

Thanks.

A quick search shows that exo-tree-view contains some gdk_window_set_cursor calls. One of them could be the cause of the bug, or we could add another one as workaround.

I downloaded the release tarball of exo from Git from the link provided by @lastonestanding (above), commented out all instances of gdk_window_set_cursor() and gtk_tree_view_set_cursor() function calls, compiled exo (./confugure), and installed it (make and sudo make install). It showed that it copied the relevant files to the relevant locations (hoping that it would overwrite my currently shipped (Manjaro) version of exo), restarted by computer and ran Thunar. But sadly the problem still remained. I do not know if my steps are correct. Please advise me and if I can, I will surely try to help further...

If you have installed the files to /usr/local, you could try with this command:

thunar -q; LD_LIBRARY_PATH=/usr/local/lib thunar

Also, it should not be necessary to mess around with the gtk_tree_view_set_cursor calls which only set keyboard focus on a particular row.

Thank you so very much Theo (yes, I installed in /usr/local). Here's what I noted: thunar -q; LD_LIBRARY_PATH=/usr/local/lib thunar, the problem reappears for all the views i.e. for Icon, List and Detailed views. If I just run thunar (which, if I am not wrong, uses Manjaro's shipped exo ver 0.12.11-5), then the problem appears only for the Detailed view.

The bug being present/exposed in the other views could be due to exo@737c8c45.

Note that, the "all-scroll" cursor is set and unset by the GtkScrolledWindow widget (gtk/gtkscrolledwindow.c#L3446).

added 5. Mouse label

I am not a programmer so excuse me if I misstate something/everything. I experimented a bit: wrote a small program where I implemented a GTK Tree View (set up a tree store, associated it with a tree model, created a treeview from the model and finally, put the treeview GTK widget inside a scrollwidget which went inside a toplevel window), it worked correctly and mouse pointer was working as it should and also it allowed the overshoot effect. Tried similarly with GTK Icon View and again, everything worked as expected. So after experimenting with exo-icon-view.c file, I realized that setting the event masks: GDK_SCROLL_MASK and GDK_SMOOTH_SCROLL_MASK to the GDK window of the associated GTK widget is messing up with the mouse pointer in the tree view that is handled by GtkScrolledWindow. A possible resolution might be:

1. Detect if the view is set to treeview or else

2. If it is treeview, unset the said masks associated with the GDK window

3. Else, keep/restore the said masks

Just commenting out line 1640: priv->bin_window = gdk_window_new (gtk_widget_get_window (widget), &attributes, attributes_mask); in "exo-icon-view.c" fixes the mouse pointer in treeview and even allows overshoot effect but completely damages (and rightfully so) the other views...

Okay, now there an additional issue: Previously, I worked with exo-4.15.2 and all my previous comments were relevant for that release. But now I downloaded exo-4.15.3 and now,the problem also occurs in both the Icons view and the Compact List views...

OK, I found a temporary workaround to fix the mouse pointer struck to "move" pointer issue::

The following insertions in exo-tree-view.c:

Insert the declaration in line 90 (or before):

static gboolean exo_tree_view_scroll_event (GtkWidget *widget, GdkEventScroll *event);

Insert the function association in function exo_tree_view_class_init line 138 (or before):

gtkwidget_class->scroll_event = exo_tree_view_scroll_event;

Insert the function definition anywhere alongside the other function definitions:

static gboolean exo_tree_view_scroll_event (GtkWidget *widget, GdkEventScroll *event)

{

ExoTreeView *tree_view = EXO_TREE_VIEW (widget);

/*check if the event occurred on the tree view internal window */

if (event->window == gtk_tree_view_get_bin_window (GTK_TREE_VIEW (tree_view))) gdk_window_set_cursor (event->window, NULL); //Reset the pointer

return FALSE; //to allow further handling of the event

}

The following insertions in exo-icon-view.c line 2542 (in the definition of exo_icon_view_scroll_event function):

gdk_window_set_cursor (event->window, NULL); //Reset the pointer

Please consider and comment...

Thanks for looking into this. Since I cannot test it, would the following change have the same effect?

diff --git a/exo/exo-icon-view.c b/exo/exo-icon-view.c
index 7b198914..47e72f12 100644
--- a/exo/exo-icon-view.c
+++ b/exo/exo-icon-view.c
@@ -1629,7 +1629,6 @@ exo_icon_view_realize (GtkWidget *widget)
   attributes.height = MAX (priv->height, allocation.height);
   attributes.event_mask = GDK_EXPOSURE_MASK
                         | GDK_SCROLL_MASK
-                        | GDK_SMOOTH_SCROLL_MASK
                         | GDK_POINTER_MOTION_MASK
                         | GDK_LEAVE_NOTIFY_MASK
                         | GDK_BUTTON_PRESS_MASK
@@ -1640,6 +1639,8 @@ exo_icon_view_realize (GtkWidget *widget)
   priv->bin_window = gdk_window_new (gtk_widget_get_window (widget), &attributes, attributes_mask);
   gdk_window_set_user_data (priv->bin_window, widget);
 
+  gtk_widget_add_events (widget, GDK_SMOOTH_SCROLL_MASK);
+
   /* map the icons window */
   gdk_window_show (priv->bin_window);
 }

Thanks...

@lastonestanding: No the changes you suggested are not fixing the pointer issue. Its remains stuck at the "move" pointer just as before...

I tried to set the GDK_TOUCH_MASK and added a handler that would detect the GDK_TOUCH_END and GDK_TOUCH_CANCEL event types and reset the pointer but it seems that all touchpad events are somehow and somewhere translated to scroll events and the touch event handler is never called...