Issue #247 - [GTK][Wayland] Drag&drop gets stuck

[SyntevoAlex]

Fixes #247

The problem was introduced in patch for Bug 541635, which accidentally
ignored calculated dragging variable, causing drag to begin
immediately when mouse is moved.

Also, it introduced a crazy loop, which, if it proceeds to second
iteration, will loop forever, because GTK events can't be processed when
main thread is busy running the infinite loop. Luckily, it seems that
the loop always exited on first iteration, and its meaning was simply to
return false when mouse is not down.

The reason why drag&drop can become stuck is not exactly clear, but I'm
confident that it was related to very short drag&drop mouse move
threshold (basically, 1px). With the regular threshold, the bug may
still be present, but it's almost impossible to reproduce.

The real case behind this bug is that when actual human double-clicks a
TreeItem, sometimes mouse will be moved very slightly when doing so,
which started a drag&drop, which got stuck and caused further problems
in applications which were puzzled by never ending drag&drop. Also, it
results in TreeDragSourceEffect image leak, because it never receives
the drag end event.

[github-actions]

Unit Test Results

     602 files       602 suites   14m 45s ⏱️
  4 013 tests   4 002 ✔️     5 💤   5 ❌ 1 🔥
24 022 runs  23 874 ✔️ 134 💤 10 ❌ 4 🔥

For more details on these failures and errors, see this check.

Results for commit d1c274e.

♻️ This comment has been updated with latest results.

[SyntevoAlex]

@iloveeclipse could you please review?

[iloveeclipse]

@SyntevoAlex : I still have RHEL 7.9 and no Wayland, so I can't really review that.
@joel-majano: you seem to have Wayland (at least GTK4 means you have more modern environment) : would you please take a look?

[joel-majano]

@iloveeclipse just took a look.

Comparing this patch against master there is a very noticeable decrease in the amount of times that dragStart/dragFinish show up in the console when clicking rapidly while moving the mouse slowly. There are instances where I can trigger the bug still, where only dragStart shows up. However, the bug does seem to have decreased in frequency significantly, and the greatly reduced amount of drags triggered seems like a more desired outcome anyway.

[SyntevoAlex]

when clicking rapidly while moving the mouse slowly

Either it's not "rapidly" or not "slowly" :)

GTK requires mouse to move 8px from starting point in order for gtk_drag_check_threshold() to detect drag.

When I move mouse slowly and click rapidly, with the patch, drag&drop never begins. When I move mouse faster, bug is still reproducible. But this is not something people would do. The original bug was easily triggered when I intended to simply double-click a TreeItem and didn't intend to do weird things.

So it can be said that the patch prevents accidental drag&drop when double clicking, and by this, it also prevents stuck drag&drop when double clicking for realistic purposes.

[joel-majano]

The original bug was easily triggered when I intended to simply double-click a TreeItem and didn't intend to do weird things.

Agreed. For all realistic cases, this patch resolves the issue. I had to do some mouse wizardry (clicking the mouse waay too fast...) to trigger the bug.

[SyntevoAlex]

You mean, move mouse too fast?
Because it has to move 8px between two clicks in order to begin drag&drop.
Or I'm not understanding something in your environment.

[SyntevoAlex]

Reminder: PR is still not merged.

[SyntevoAlex]

@akurtakov is there anything that block this PR from being merged?

[akurtakov]

I just haven't looked into it. If you're confident, just merge it.

[SyntevoAlex]

OK, let's merge it, then.