"Copy Cut Paste" menu appearing when it should not

[lokman2k5]

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

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)

[Doublonmousse]

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)

[lokman2k5]

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?

[flxzt]

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

[lokman2k5]

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

[Doublonmousse]

So the position is (0,0) when this occurs, so we can ignore it when that happens

Also a slew of broken accounting messages cause gtk ...

Edit : this didn't work

[Doublonmousse]

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

[lokman2k5]

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?

[lokman2k5]

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

[Doublonmousse]

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

self.touch_long_press_gesture.set_propagation_phase(PropagationPhase::Capture);

And change the connect_start of this gesture to add a

self.touch_long_press_gesture.set_propagation_phase(PropagationPhase::None);

Edit : This didn't work (https://github.com/Doublonmousse/rnote/tree/fix_1220)

[PietHelzel]

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.

[Kneemund]

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.

[Kneemund]

Would be nice if some people could test if the PR fixes the issue on their setup. You can use this flatpak build, or checkout and build it yourself :)

I personally can't reproduce this bug with anything other than zooming. The author of this issue described that it occurs when scrolling - I'm not sure how that could happen.

[PietHelzel]

Would be nice if some people could test if the PR fixes the issue on their setup. You can use this flatpak build, or checkout and build it yourself :)

I personally can't reproduce this bug with anything other than zooming. The author of this issue described that it occurs when scrolling - I'm not sure how that could happen.

@Kneemund I tested your flatpak, and could not reproduce the issue anymore \o/