Add delay before triggering drag and drop / Too easy to move files when clicking them

Feature requests
1

Steps to reproduce

  1. Open sandbox vault on macOS.
  2. Click any file under Guides while slightly moving the mouse.

Did you follow the troubleshooting guide? [Y/N]

Y

Expected result

The selected file is opened and is still in the Guides directory.

Actual result

The selected file is opened and it was moved to the root directory (parent of the Guides directory).

Environment

SYSTEM INFO:
Obsidian version: v1.5.3
Installer version: v1.5.3
Operating system: Darwin Kernel Version 23.2.0: Wed Nov 15 21:53:18 PST 2023; root:xnu-10002.61.3~2/RELEASE_ARM64_T6000 23.2.0
Login status: logged in
Catalyst license: none
Insider build toggle: off
Live preview: on
Base theme: light
Community theme: Solarized v1.0.9-beta
Snippets enabled: 0
Restricted mode: off
Plugins installed: 7
Plugins enabled: 6
1: TimeStamper v1.3.0
2: Dataview v0.5.64
3: QuickAdd v1.6.1
4: Excalidraw v2.0.13
5: ExcaliBrain v0.2.11
6: Periodic Notes v0.0.17

Additional information

In other macOS apps, like Xcode or Finder, the move gesture with the mouse isn’t as sensitive. There is a slight delay before it is triggered, and requires a little bit of hovering to confirm the destination of the move.

In Obsidian, there are no such delays, hence I’m having this problem for the first time. I accidentally move files at least 1-2 times a day, and that’s with very little mouse use to begin with.

7 Likes
2

I have never run into this problem. I am gonna move this to FR and see the feedback we get

3

It happens mainly when I’m using my ergonomic mouse (Lift Vertical Ergonomic Mouse | Logitech), which uses more arm for movement.

Doesn’t happen when I’m tapping on my MacBook trackpad.

2 Likes
4

I use the same mouse. Perhaps, you have the habit of holding on the clicked button.

5

I’m also experiencing this problem. It’s far too easy to accidentally move files and folders.

3 Likes
6

Could be related to this issue:

7

THIS. Click on a file inside a folder and the slightest twitch sends it off into lands unknown. Similar issues with some UI elements—the icons move rather than get selected.

It’s a very subtle behavior, but the Obs UX is not following standard OS level behaviors.

Also, moving files in this manner is not undo-able. Very frustrating.

3 Likes
9

I don’t think the problem is the lack of a delay. Here’s some more information on the behavior, contrasting Obsidian with macOS:

In, say, a Finder window, clicking a file highlights the file. Subsequently click-hold + dragging the file begins to move the file to a place of your choosing. If you fail to place the file on a suitable target such as another folder, or choose to abandon the operation by letting up on the click, the file returns to its original position.

In Obsidian on the other hand, clicking a file inside a folder opens the file in the view pane. A subsequent click highlights the file. At this point, click-hold + drag highlights the file and begins the move operation, showing the destination of the operation underneath the selected file. If you do anything at this point other than hit [esc], the file is moved out of the folder to the root directory, with no visual bread crumbing to help you see where it went. It’s instantaneous and ruthless, and explicitly does NOT move the file to the location described in what I’ll call the “move destination.”

This behavior is excruciatingly backwards to the expected behavior, and results in both challenges with opening files and managing the file system, since the failure mode results in chaos rather than returning you to your starting point.

This is a bug.

2 Likes
10

Try to read the thread linked above by @ariehen

11

I read that thread, and yes, that’s a bug, too. A different bug, but one I have noticed less frequently. What I’m describing above is a problem both with where files get moved as well as the UX behavior when moving files.

Hopefully 1.5.4 fixes both issues.

12

It’s not different. Please, read the whole thread. It’s describing what you are describing.

13

You’re probably right. If these are indeed the same issue, then I look forward to seeing improved results in 1.5.4. Thanks.

14

let’s hope that it fixes your problem.

15

I have the same issue, it is very bad. I use a Wacom tablet instead of a mouse (because of wrist pain). A simple “tap” moves the note out of a folder. It is a huge problem.

2 Likes
16

TL;DR: When fixing, please keep in mind that this is two separate issues (not counting @skoobe’s multi-file-drag issue):

  1. Obs interprets some clicks from over-sensitive HIDs (pen+tablets, some mice) as drags; these “drag-clicks” do not result in the file opening as expected, causing frustration.
  2. A bug causes dragged files (and folders), released within the same folder, to moved up one level in the folder hierarchy, causing frustration.

Issue #1 triggers #2, but only fixing #2 makes #1 only slightly less frustrating. Please treat as separate issues, and please fix both.

Just to weigh in with my experiences — I also have this problem, and, like @digross, I use a Wacom tablet (specifically Cintiq 16") instead of a mouse.

I’ve also had this problem (just the drag-instead-of-click part, not the hierarchy jump issue) with other software in the past, specifically in a Wacom / pen+tablet HID context, and the issue seems to be that you’re more likely to move the pen tip while clicking on a file (which translates as a left click + drag, if not accounted for) when using pen+tablet than you are with a mouse (depending on the sensitivity and type of the mouse, of course, as seen in this thread).

The few times where I have managed to get the relevant Devs to fix the issue, the solution is to implement some sort of [distance moved (in pixels) before triggering ‘drag’] in the app’s code.

I agree with @WhiteNoise that this is related to the other issue, and with @umami that the expected behavior for initiating a drag, and then dropping the file “on itself” (where it already was), or into the folder it is already located in, is that the drag action should be cancelled.

I did some further testing with a file nested in five layers of subfolders, and even if you drop the file on the folder already containing it (current folder), the file still gets moved up one level (and always just the one level) in the hierarchy (parent of current folder), even if the tooltip says “[filename] - move into [current folder name]” when drag-hovering over the file itself, or anywhere else in the containing folder (or on the containing folder’s title).

Apart from pressing ESC (not a thing when you were just trying to click, not drag), there really is no way to avoid moving the file up one level.

Since the main issue here seems to be that “drag file to its current containing folder” is broken (which, incidentally, is triggered for some of us because of pen/tablet use or over-sensitive mice), I suspect that this issue can be partially corrected by implementing/fixing [cancel move action if file is dragged to its current containing folder].

However, when implementing the fix, please keep in mind that the over-sensitiveness of the drag function, combined with the move-up-one-level-in-the-hierarchy bug, is not the only issue.

Even if the hierarchy bug is fixed by [cancel move if destination same as current location], everyone who was affected by it will still experience drag-instead-of-click (just without the hierarchy bug, hopefully). Since the drag option does not open the file in question (at least in my tests), we will still experience clicks that don’t always open a file (because Obs thinks we’re dragging it, not clicking it), which is frustrating.

As such, please look into some sort of [only trigger ‘drag’ after cursor has moved X pixels] solution in addition to fixing the hierarchy bug. A suggestion would be 3-10 px, but less might do it.

Granted, this will lead to dragging feeling the tiniest bit “sticky”, which some might find annoying. A compromise would be to have the “drag delay” fix as a (default: off) option in Settings, probably in the Editor → Advanced tab/section.

If you’re feeling really fancy, the distance-in-pixels-before-drag-triggered value could be user-defined, resulting in this hypothetical setting:

Settings → Editor → Advanced:

File & folder drag delay
Requires dragging a file or folder a few pixels before the actual drag action is initiated; prevents clicks from certain HIDs (pen+tablets, very sensitive mice, etc.) from being interpreted as drag actions.

:radio_button: Default amount (3 px)

:radio_button: Custom amount

Number of pixels before drag action is initiated: ___ px

  • Add standard toggle to enable/disable setting, default ‘off’.
  • Options (Default/Custom) grayed out when toggle is ‘off’.
  • “Number of pixels …” + text field grayed out when Default is selected.

I hope the “drag delay” can be implemented, even if the extra Setting is a bit out of scope. Either way, I’m looking forward to the hierarchy bug hopefully being fixed in 1.5.4! :slightly_smiling_face:

3 Likes
17

Thanks for your thorough explanation. This was interesting to read. Describes the problem perfectly.

1 Like
18

Thank you! Thought it was worth fleshing out the situation some more, as I eyed an opportunity to ease the friction of being a pen+tablet user by getting this issue fixed properly; the “drag-click” is, sadly, an all too common occurrence, probably because there aren’t all that many of us tableteers :blush:

My personal workaround / quick fix is having my Cintiq to the right of my keyboard (I’m right-handed), and an Apple Magic Trackpad to the left, and then accomplishing a lot of my clicks by hovering the pen over the thing I need to click on, and performing the actual click with a tap on the trackpad. Essentially, cursor interaction becomes a two-hand operation, but it works really well (and it’s also awesome to have the trackpad available for scrolling tasks).

Incidentally, if anyone is having wrist pain issues / RSI, I can highly recommend giving pen+tablet a try! I used to get really bad RSI, and I am on a computer a lot, both for work and leisure. I switched to pen+tablet … *checks notes* … 27 years ago(!), and haven’t had a single HID-related injury (or even inconvenience) once since then.

Having converted some 8+ trainees and colleagues from mouse to p+t users during my years as the head of a graphics department, I can offer a 95% guarantee that getting over the “this feels weeeird”-hump takes exactly 3 days.

At that point, the chances of mouse recidivism drops to very near zero; once you go p+t, you rarely go back, provided that you:

  • Make sure the tablet is not in “mouse mode” (tablet should represent entire screen, and you should never need to lift your hand and move it back to get further in a specific direction).
  • Enable “force proportions” for the tablets active area (the distance your hand needs to travel to move the cursor in any direction must be identical).
  • Set the pen button to “right click”. If the pen has two buttons, I suggest setting the lower one to “right click”, and the upper one to “middle click” (great for opening browser links in a new tab).
  • Enable “hover click” (allows using the pen button for right clicks while not touching the tablet).
  • Quickly learn that the pen never leaves your hand; when you need to type on the keyboard, you simply tuck your thumb towards your palm, effectively “rolling” the pen along the edge of your hand, and moving it from a vertical to a horisontal position (in relation to the desk/keyboard). When you’re done typing, you simply reverse the thumb tuck, and steady the pen tip with your index- and middle finger.

Even the cheapest Wacom pen+tablet, the incredibly stupidly named “One by Wacom” (not to be confused with the “Wacom One” — you can’t make this shit up :roll_eyes:), currently $30, is a perfectly reasonable starting point, if you’re just looking to replace your mouse.

OK, I seem to have gotten a bit off-topic … I’ll stop now :sweat_smile:

19

nightgolfer did fantastic explanation, I wanted to add that I also face the same issue but on both Windows and MacOS.

20

Just installed the beta version 1.5.4, and this problem appears to be fixed!!!
Now, notes do NOT move into the main value folder when I use my tablet pen. Dragging inside a folder does NOT move the note out.
Yay!

21

Nice, going to have to give that a test for my self.