Repository: flxzt/rnote (language: rust)

Issue:
"Copy Cut Paste" menu appearing when it should not
When I am using the app with my touchscreen, A menu on the top-left corner sometimes appears and stops whatever I am doing(eg scrolling), I'd have to click again anywhere on the screen to make it go away

**Console Output**  
2024-09-17T17:06:43.919340Z DEBUG rnote: .. tracing subscriber initialized.


**Screenshots**  
![Screenshot from 2024-09-17 20-01-34](https://github.com/user-attachments/assets/30428cb1-da01-494b-a59b-b04b46b241aa)


**Desktop (please complete the following information):**  
 - OS: Fedora 40
 - App Version: Rnote v0.11.0
 - Installation Source: Flatpak
 - Desktop Environment: Gnome 46.5
 - Display Server: Wayland
 - Input Source: On-Screen-Tablet

**Additional context**  
I am using a thinkpad yoga x1 3rd gen. with a wacom ISDv4 5148 (builtin touchscreen)



Discussion / hints:
My hope is that I can prevent this from happening based on the position x,y returned for the popup (either 0,0 or some incorrect position)

I can't find a related gtk issue (there was no change on the rnote side that would explain the sudden apparition of this bug, it didn't happen with gtk 4.12 and happens with 4.14 and 4.16). I though I saw something similar though, will search some more (and probably open a new issue)
I think then we should report this to gnome? they will also tell us that it's unrelated to gtk and we should report it back to the application dev, wouldn't they?
No I think it has to do more with how the long-press gesture is activated - it seems to be a regression that got introduced by #1134
if i long-press using fingers, it shows the same dialogue(copy cut paste) but it vanishes as soon as i left my fingers to select an option
So the position is (0,0) when this occurs, so we can ignore it when that happens

![image](https://github.com/user-attachments/assets/7f48c2b0-ae86-4a1c-8672-c4604620cde6)

Also a slew of broken accounting messages cause gtk ...

Edit : this didn't work
The best I can do is do the same thing as before if (x,y) is not close to (0,0) and if not, present then immediately close the popup.

This at least doesn't totally break the right click (whereas doing nothing does, no right click will ever work after the first spurrious one gets rejected) but it breaks other gestures (because everytime the spurrious menu is called, the current gesture is interrupted). So things like zooming with two fingers can stop working midway through the gesture
can't we create something like a timeout? like wait this much seconds and only then show the popup, do not show it if scrolling or not pressing for like 5 seconds, only show it if a single finger is pressing for 5 seconds, isn't that possible? if not, why not?
I found these issues that I can actually confirm on the gnome bug tracker, might be related:
https://gitlab.gnome.org/GNOME/gtk/-/issues/5540 (this is on the top left corner as well, so that confirms it)
https://gitlab.gnome.org/GNOME/nautilus/-/issues/2872
Actually, (after looking at #1246 and the PR therein), was the original bug/crash triggered upon the launch of the `connect_cancel` or because of the `set_sequence_state` part ?

To me it seems we could replace the `set_sequence_state` (that was in the removed part of the code here https://github.com/flxzt/rnote/pull/1134/files) part by a 
```rs
self.touch_long_press_gesture.set_propagation_phase(PropagationPhase::Capture);
```
And change the  `connect_start` of this gesture to add a 
```rs
self.touch_long_press_gesture.set_propagation_phase(PropagationPhase::None);
```

Edit : This didn't work (https://github.com/Doublonmousse/rnote/tree/fix_1220)
According to the issue in GTK linked above (at https://gitlab.gnome.org/GNOME/gtk/-/issues/5540), the fix has to be done application-side as described in comment https://gitlab.gnome.org/GNOME/gtk/-/issues/5540#note_1801167. I dunno if this is the actual fix or what exactly it means, just want to make sure the devs and other people with this issue are aware.
I don't think that this issue is related to anything that has been linked here so far. I believe that it occurs because the event sequence of the zoom event is claimed when it starts and **always** denied after it ends, even if it is not canceled. This causes the sequence to propagate further and reach the long press gesture.

Fix patch:
diff --git a/crates/rnote-ui/src/canvaswrapper.rs b/crates/rnote-ui/src/canvaswrapper.rs
index e94ad1bdba..e27f2229ff 100644
--- a/crates/rnote-ui/src/canvaswrapper.rs
+++ b/crates/rnote-ui/src/canvaswrapper.rs
@@ -564,8 +564,7 @@ mod imp {
                 self.canvas_zoom_gesture.connect_end(clone!(
                     #[weak(rename_to=canvaswrapper)]
                     obj,
-                    move |gesture, _event_sequence| {
-                        gesture.set_state(EventSequenceState::Denied);
+                    move |_gesture, _event_sequence| {
                         let widget_flags = canvaswrapper
                             .canvas()
                             .engine_mut()


Test patch: