Hey everyone, I posted on cachy’s forum and found people that have the same issue, thought I would also post about it here. I’ll include their posts as well.
My issue is that I keep dragging my tabs on Firefox, the icon of Discord servers or just folders/files all the time when I don’t mean to, it feels like the ‘held click/drag threshold’ is too damn sensitive. This doesn’t happen on Mint nor Windows.
expected behavior : when the mouse is in motion during a fast click on an icon/tab it should only click the icon/tab or the icon/tab shouldn’t move enough to be dragged
observed behavior : when the mouse is in motion during a fast click on an icon/tab it currently drag icon long enough to move them to a new location and it drag tab long enough to create a new window,
the behavior is observed only on cachyos using kde. i tested on windows and it worked as described in expected behavior.
User Kat wrote:
I’ve also been having this issue. I’ve only experienced this on CachyOS, not on Windows or other Linux version (with both the same and different DE’s). I’ve used two different Pulsar mice so if it’s a hardware issue then they’re both affected. What I do know, is it’s absolutely not user error.
I suggest that the drag threshold is set (I think maybe 6-10 pixels’) in code now, not revealed to settings after the migration to libinput.
Gamers like to flick the mouse - and clicking on the move means there’s a risk of the mouse moving 6 pixels before the click is released = drag function.
TL;DR
Average click might be 80-100ms which is enough for a fast moving cursor to travel over the threshold.
The threshold is no longer adjustable in Plasma settings… so the solution is not to try ‘drive by’ clicking.
+1 this is driving me mad now that I switched to nvim - I was tolerating this behaviour elsewhere always accidentally dragging everything and selecting text, but now in nvim trying to be productive 10+h/day at work, is actually infuriating. (Multi monitor, you do a lot of clicking between to ensure active window.) Even when I’m absolutely stationary, the act of clicking the button on the mouse nudges it enough to register as drag and not a click.
If anyone knows of any tricks to increase these “values” please do share.
If I use the mouse for this, I present windows and click the one I want to to go to, not sure how you can drag that. I have ‘Grid’ and ‘present windows’ on my thumb buttons for this.
If the window in on the same desktop, then again - a simple keyboard shortcut to go to the other window is most effective, there are many options in the keyboard shortcuts.
Mostly I just use Ctrl_Alt_ARROW keys to swap when there are a couple of windows to work with on a desktop.
There are many ways to select windows from all desktops/monitors/workspaces/activities.
With your taskbar, you can also directly select those icons using Meta+1-9. That means if you had 4 kitty windows on the same desktop, and that’s the first item on the taskbar (even if that’s hidden) you can press Meta+1 to walk through them.
Frankly, the idea of reaching for the mouse to reach a visible window is the clumsiest of all I can think of - presenting windows on the current desktop, all desktops, or whatever (or desktop grid) is just so much more direct.
Look I’m not going to re-learn how to use computers after being an engineer and using them certain way for 30+ years, 16 hours a day. I click at whatever empty space a window has to go into it. If that’s nvim in terminal it goes into visual mode and starts selecting text because the mouse input was incorrectly registered as HOLD instead of CLICK input. That’s wrong, it’s a bug that needs fixing. And frankly even if I wasn’t clicking to select windows, even if I did want to use click to change cursor position in nvim, it still Should Not Select Text don’t you think…
Also I’d like you to use slack or browser to copy text you’re working on without mouse. Good luck have fun. I’m already holding it, therefore I use it to select window as well - I’m not going out of my way to reach for it to do that. Your way isn’t the only way, it’s pretty simple, everyone uses computers differently.
Just demand it’s made to fit you and make no effort to fit what’s offered.
I just thought I’d point out a few of the many alternative workflows that I learned in my 30 years using computers.
However, I think it’s more a problem with sloppy mouse use than anything else, whilst I can replicate this, I have to deliberately click and drag.
So it’s an issue with drive-by clicking, and the migration to libinput means you can no longer set the drag threshold beyond the 10 pixels it’s already set to.
Main character syndrome aren’t you - saying that common use case (much more than yours) is me being wrong in how I use it… How sad.
This is a common bug experienced by many people and it needs fixing - despite that fact I never demanded that it’s fixed, I merely asked for advice for any known workarounds to configure libinput, what needs changing to increase thresholds.
You’re not contributing, please take it elsewhere.
Not everyone has the same motor skills, and it’s not helpful to deride people as “sloppy”.
Personally I’ve had one of the same issues that OP describes (accidentally dragging a tab in Firefox so it detaches into a new window). Not all that often, but enough to be annoying.
Yep, my skills are far from sloppy, I just have higher pixel density monitor. Sorry for that. It’s a hardcoded pixel value which has different effect in the real world with different monitor size, dpi, you know, not everyone using the same hardware.
Also frankly I don’t think that it’s 10 pixels. That sounds like a far more reasonable value than what I’m noticing - it starts dragging immediately with 1 pixel movement.
Selecting text in terminal is a single pixel of movement. Literally a single pixel - I even recorded a video but I’m not allowed to post it here - or to even link to it so..
It seems to be a handful of pixels with the @pg-tips use case of dragging a firefox tab - it picks up the tab after what looks to me like 9 pixels (not 10). On my screen that’s about half of a single letter width. That’s less than 1mm of real world size. That’s also incredibly sensitive that (depending on mouse click resistance, dpi, etc) you might move that far when just trying to be stationary and clicking.
The difference between a clean click and a sloppy one is 4-6 pixels.
Pointer speed - dpi, acceleration and sensitivity should be set lower to let you click without moving the cursor too far… higher sensitivity means even tiny errors make larger errors.
I find dpi set from 400-600 is optimal for desktop. If I remember rightly, something I don’t remember setting in over a decade, about 6 pixels is good as a threshold.
It’s not purely about motor skills… but if it’s a problem, then it’s fine to request a setting and then find a more suitable way of doing the job.
So my pointer speed and acceleration are set about right for me to:
Get around the screen at reasonable speed
Land where I need to click, without too much trouble
Subjectively, mouse movement feels about the same as it did on Windows, but I didn’t have the “accidentally drag Firefox tab” problem on Windows. OP also says that they experience it on Plasma but not on Mint (presumably Cinnamon).
So it would be good to have a setting.
As a separate issue, I sometimes want to go to really low pointer speed (e.g. for fine editing of graphics). I had a script that did that for me in Windows when I held down a hotkey, but even the lowest setting in Plasma isn’t low enough for me. That’s not directly part of this issue though, one for a separate thread.
Overall, I’d like to see the ‘Advanced Settings’ section brought back… I’m curious how much harder that would be with Wayland, as I’m guessing that was where it was dropped.
I have managed to drag out tab with 1 pixel of movement.
Other user also see dragging after 1 pixel
With discussion on other forum I have found Kde can’t change this behavior from them. So you either have to use youre machine slower or find another gui
That’s really odd - I can definitely drag the mouse a couple of pixels without the tab popping off… when I tried it with the magnifier, it’s definitely over 5 pixels, maybe nearer 8.
Dragging any window (firefox, konsole, …) in KDE is both, a time threshold, as well as distance. Dragging large distance quickly will drag immediately. Clicking and holding on a window for a while, will innitiate drag after a small fraction of a second, without a single pixel of movement. (Unlike in firefox tabs or terminal text which is distance only, no time threshold there)
So far I found 3 distinctly different forms of mouse “HOLD” input that are completely different from one another. Some of these might be configurable somewhere - suggestions welcome. (I saw something in QT specifically for instance..)
I recorded videos of all three, can’t post them here - not even as a url, so you can’t see the proof if you needed one - it’s a real problem, WE (many people) are not hallucinating, or being sloppy.
I must highlight again that an absolute pixel distance is frankly stupid. It needs to be relative to screen size, dpi, mouse sensitivity, etc. Real world experience varies, pixel size vs real world travel distance can be vastly different. As such, it needs to be at the very least configurable (in all 3 cases above) so that the user can make-do regardless of what hardware they use - or even regardless of what disability they may have (what if they have no hands and use their feet?)
I suspect it’s not only Kde. Something else is causing this interaction in combination with Kde. Our machines aren’t behaving like yours for some reason.
Otherwise I suspect this problem would be talked about more.