I was messing around with Kwrite when I noticed that if I right click on selected text WHILE at the same time moving the mouse to the right, it acted as if I clicked on cut (which is the first item in the menu). I even filed a bug report for kwrite here https://bugs.kde.org/show_bug.cgi?id=410236

But now I realize this happens even in the terminal and everywhere else. And it actually happens because releasing the right mouse button acts as a click to whatever menu item the mouse happens to be hovering on top of. So considering that I use a very high speed (dpi or whatever) for my mouse, it may happen that even if I right click normally (which takes a split second), the mouse may be already hovering over the first menu item and act as if I clicked it. If i deliberately hold the right mouse button and release it on any menu item, it acts as if I click it, so this makes me think that it's some dumb feature and not a bug.

So yeah, why does this happen and how do I get rid of it? It annoys the hell out of me and it keeps happening because I usually work fast with the mouse. If it cannot be disabled that would be a complete dealbreaker for me because I can't go around accidentally clicking menu items while working.

I suggest to add this comment to the referenced Qt ticket.

Interesting, so this was reported back in 2006 and nobody ever did anything to fix it. Considering it has happened to me like 100 times in a couple of days while working on txt files, not even doing something obscure that pushes a computer to its limits; I expected it was some kind of features for weirdos who like to click on menu items by releasing the right mouse button (who am I to judge?), not an actual bug that was first noticed back in 2006.

So let me change the question, is there any workaround for this? It annoys the hell out of me, it keeps happening and now I am almost afraid to right click because I might trigger something accidentally and not notice it (such as cutting a piece of text) until it's too late.

I wonder if it also depends on the specific Application Style being used. I noticed this a lot (more) when I was using Kvantum (with the Sweet theme), but I don't recall this being much of a problem when using Breeze or StyleProject.

It would be easy to solve I guess, they'd just have to change the right click behavior.
Right now it's as follows
Button is pressed -> menu appears -> button is released
Also the release action can trigger menu items

It should be changed like so
Button is pressed -> button is released -> menu appears

Or just add some config that disables the ability to trigger menu items with the right click. Anyone knows if there is some way to change this behavior? That would solve the issue completely (besides, why would anyone select stuff with the right click, is there anyone in the world who does this?).

if it also depends on the specific Application Style being used

The platform theme can set a ContextMenuOnMouseRelease hint.

This is only set by Qt's windows platform theme. Even if plasma's theme set that, it won't help you with GTK applications and this property is also not accessible to QML, so it won't help you there either.

I use context menus by press and holding the right click, moving my mouse to the desired option, and releasing it. It drives me insane when I can't do that on a Windows machine.

I had a slow day at work so I researched this for a while and after something like two hours of trial and error I found a working solution even though it's one I would consider pretty much a hack. I found many posts on various distros who complained about this behavior where the right click release triggers context menu items.
Eventually I found this: https://askubuntu.com/questions/178373/ ... the-button

There is a config for the tool sxhkd, which from what I can tell is a button remapper of sorts. I played with it for a while and was able to make simple configs that would remap keys or do macros. Anyway, this script resolves the issue by adding a delay to the release event (credits to the genius who figured this esoteric script out from the above link)

~button3
for id in `xinput list | grep 'slave pointer' | grep -v XTEST | sed -e 's/.*id=\([0-9]\+\).*/\1/'`; do xinput set-prop $id "Device Enabled" 0; done; \
xte 'mouseup 3' 'mousermove 0 -1'; \
sleep 0.3; \
for id in `xinput list | grep 'slave pointer' | grep -v XTEST | sed -e 's/.*id=\([0-9]\+\).*/\1/'`; do xinput set-prop $id "Device Enabled" 1; done

I have absolutely NO IDEA on how this was figured out or how this works, all I can tell is that the sleep and device enabled parts are the key to the whole thing. But after I managed to get sxhkd working, I don't seem to trigger menu items with the release button anymore. Right now I tested it on my virtual machine, this evening I'll try it on my computer.

kbroulik wrote:

I use context menus by press and holding the right click, moving my mouse to the desired option, and releasing it. It drives me insane when I can't do that on a Windows machine.

You absolute madman.

kbroulik wrote:The platform theme can set a ContextMenuOnMouseRelease hint.

This is only set by Qt's windows platform theme. Even if plasma's theme set that, it won't help you with GTK applications and this property is also not accessible to QML, so it won't help you there either.

I use context menus by press and holding the right click, moving my mouse to the desired option, and releasing it. It drives me insane when I can't do that on a Windows machine.

This behaviour seems to have changed recently. With qt 5.15 context menus no longer activate on releasing the right mouse button as they did previously.

I, too, used context menus in the same way as kbroulik did and find this new behaviour annoying. Is there any way to make it work like it used to?

This has been one of my pet peeves as well.

The accidental selection of the top menu item on context menus happens to me constantly. I'm not holding the mouse dead still when I press the button. The act of pressing the button makes me move the mouse a small bit unless I concentrate on not doing so, and it's even worse on my laptops with clickpads.

If you use the press-hold-select-release method, the way the right button works as far as the context menu is fine, but if you don't, the setup as-is is unworkable, IMO. This could easily be fixed with a pref to bring up the context menu on button-up instead of button-down, or to have a user-defined hysteresis setting (in px) that will define how much of a movement will be ignored between button down and button up. If the user set that to a high value, it would have the effect of preventing this unwanted effect, while leaving it intact for those who wish it (and they would keep the default setting, which would be to keep things as they currently are).

I used Windows for a quarter of a century before I moved to Linux, and I'm kind of an old dog at this point (though not so much that I was willing to tolerate that disaster called Windows 10)-- I want the system to conform to my way of doing things rather than forcing me to conform to its own. That's kind of the point of Plasma, isn't it? I know this seems to be a Linux-wide convention, but I'm not asking for it to be changed by default, only to have the option to change it.

MRK0017 wrote:There is a config for the tool sxhkd, which from what I can tell is a button remapper of sorts. I played with it for a while and was able to make simple configs that would remap keys or do macros. Anyway, this script resolves the issue by adding a delay to the release event (credits to the genius who figured this esoteric script out from the above link)

~button3
for id in `xinput list | grep 'slave pointer' | grep -v XTEST | sed -e 's/.*id=\([0-9]\+\).*/\1/'`; do xinput set-prop $id "Device Enabled" 0; done; \
xte 'mouseup 3' 'mousermove 0 -1'; \
sleep 0.3; \
for id in `xinput list | grep 'slave pointer' | grep -v XTEST | sed -e 's/.*id=\([0-9]\+\).*/\1/'`; do xinput set-prop $id "Device Enabled" 1; done

I feel exactly the same as you. This a trivial feature that obviously annoys whoever has learned to use a computer with Win10. Also, it causes unwanted behavior when the context menu is very tall and you right-click near the left side of the screen. In this case, the context menu opens while the cursor is inside, doing whatever operation the cursor was hovering.
This happens to me with Thunderbird (v68.12.0 (64-bit)) open on my 1366x768 res laptop screen. It is driving me nuts because sometimes it archives or deletes emails without me even noticing.

Thank you very much for sharing this really cool but cumbersome solution. It does work but it lag's my system every time I right-click. So that is even more of an inconvenience than living using my right-mouse button with constant anxiousness to not click it (press and release) in the wrong place. Has anyone come with a more straight forward solution for this seemingly simple issue?

It is a matter of taste, analogous to KDE choosing single-click as the default behavior to open files... I really don't care as long as I can configure it to what I like.