My research on getting preferences from each platform:

Qt5's QtStyleHints [1] has the tantalizingly-named methods startDrag{Distance, Time, Velocity}. However, digging through the 5.7 code seems to indicate that none of the preferences are fetched from the OS. There are only TODOs.

OSX seems to only have a default (preference that isn't exposed by its Settings app) [2] for the drag&drop text delay, NSDragAndDropTextDelay [3].

Windows has X and Y hysteresis before a drag starts. The values can be obtained by calling GetSystemMetrics [4] with the SM_CXDRAG SM_CYDRAG constants. The values can be set (useful for unit tests?) by calling SystemParametersInfo [5]. Windows sends a WM_SETTINGCHANGE [6] message to top-level windows when settings change.

Linux is (as always) complicated. There's a drag-threshold setting under the org.gnome.settings-daemon.peripherals.mouse [7] Gnome configuration key.


[1] http://doc.qt.io/qt-5/qstylehints.html
[2] https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/UserDefaults/AccessingPreferenceValues/AccessingPreferenceValues.html#//apple_ref/doc/uid/10000059i-CH3-SW1
[3] http://apple.stackexchange.com/a/166587/21616
[4] https://msdn.microsoft.com/en-us/library/windows/desktop/ms724385(v=vs.85).aspx
[5] https://msdn.microsoft.com/en-us/library/windows/desktop/ms724947(v=vs.85).aspx
[6] https://msdn.microsoft.com/en-us/library/windows/desktop/ms725497(v=vs.85).aspx
[7] https://github.com/GNOME/gnome-settings-daemon/blob/master/data/org.gnome.settings-daemon.peripherals.gschema.xml.in.in

For Linux, there's also an X11 XSettings spec [1] that defines a generic mechanism for sharing common settings, whose scope explicitly includes drag and drop threshold. The spec does not define specific settings, but I used a node.js module [2] to list the settings on my workstation and found a "Net/DndDragThreshold" setting set to 8, which seems correct.

We seem to have code that reads from gconf, but no code that reads from xsettings. The latter is more generic though, if we want to get to a point where we don't depend on GTK on Linux.

[1] https://standards.freedesktop.org/xsettings-spec/xsettings-latest.html
[2] https://github.com/sidorares/x11-xsettings

Until this is fixed, couldn't the drag threshold constant at least be increased to something closer to at least 30px or 40px (css pixels) or so. Currently it seems to be about 1 or 2 px which is absurdly little when using a hi-dpi mouse and a hi-ppi monitor.

It's better to have a too large threshold than a too small threshold, because if the threshold a bit larger than the users preference it's a bit annoying, but still usable, but if it's way to small for the users preference (because of a sensitive mouse, or impaired hand motor control, or tremors) it's almost impossible to click without starting a drag operation.

This is especially true for other applications built on chromium such as Atom.io where this issue makes it almost impossible to use the tree view without constantly moving files by accident:  https://github.com/atom/tree-view/issues/919

It may be insufficient to just use system settings

From comment 2, OS generally have one setting for drag sensitivity.

To avoid false positives, it has to be set higher. To ensure smooth drag - lower.

If I try setting it to 20 pixels, window becomes very unresponsive to drag. Even at 8 pixels it is bad, when you drag it nearby. But accidental drag at this threshold already happens.

While false positives are a big problem in browser, it is not a problem in OS in general:

1) In native apps developers explicitly define draggable items, whereas in browser everything is, by default, draggable. I.e. in native app there can be no false positive when clicking a menu item.

You could set "draggable" to false on the links that don't need it, but no one does it, it also breaks a drag'n'drop of a link to a different application.

2) For items that are draggable, in OS, double-click is a standard way to trigger their main action. In browser - single click is the standard for all links.

So it's natural for OS to have single setting, but insufficient for browser.

In browser, drag action triggered by simple click = failed click. I suspect it is a usual problem, people just don't complain because they simply click second time and forget. But given that second click is done with more effort = strain on the hand, there's also a health concern. +, as comment 4 says, it's and accessibility problem.

Possible solution:

In addition to using system setting, add (browser own) extra setting, which defines a different drag sensitivity for the elements that have a link or click/mouseup/mousedown events handlers attached.

I don't expect that we'd expose a setting, the bar for those is really high these days. If there's enough demand, we might expose an extension API, like we do for advanced network settings. That would be a different issue that would follow up this work.

How often do you really need to drag something just 4px anyway? In what perverse situations are the drop targets less than 40px away from where you started dragging? Having drag start feel slightly sluggish is a small price to pay for actually being able to click something reliably. 

Even with 40px threshold you can still drop something less than 40px away by just dragging more than 40px and then back a bit. The links apparently have 40px threshold for a reason (even though it shockingly it seems you are seriously considering reducing it to just 5px: https://codereview.chromium.org/2401503002/ Please reject this suggestion!), because without a big threshold for links, clicking links wold be terribly painful.

If you want to homogenize the thresholds, please pick the *largest* threshold not the smallest; it's already almost impossible to deselect text using the mouse if you've accidentally selected all the text on the screen in Chrome because it constantly tries to drag and drop instead. Imagine browsing the web if every time you try to click a link it's a 5 second battle with the mouse trying to go to the link rather than dragging it.

If 8px threshold is frustratingly large for you, you must have either superhumanly steady hands or a extremely low resolution mouse or both. Because for me 8px is about how much my mouse moves on average when just trying to click unless i force the mouse hard into the mousepad first. (And that's with mouse accelleration disabled... You could say I have a too high resolution mouse (3800dpi I think it is) but it works just fine for everything else except clicking stuff in Chrome and Atom.io without accidentally dragging them.)

Please, default to something usable for everyone until you can read the the system preferences. Optimize for user with less than average motor skills rather than those above average. (And if that's an impossible compromise just add an about:flags setting; who cares how much crap that's in there if the default is sensible...)

#7: The current threshold is set to the default setting for Chromium's host OS. We use this value because most users don't change this default setting, so this value makes Chromium's behavior match the user's other apps for most users. This was agreed upon with UX, and is very unlikely to change.

I know and understand that all people are different and use different peripherals, and I would like to see us follow the OS settings. This is why I created this issue. Unfortunately, we don't have infinite engineering resources, and we have a large number of issues to tackle. This issue lets you see that we're aware of the problem, and how we prioritize fixing it.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot