Right-click the entry to bring up the context menu.
Left-click a directory near the top.
The application is treating this as a drag & drop operation, and moves the file into the subdirectory.
The issue seems to be with the way FileListDataGrid_PreviewMouseLeftButtonDown and FileListDataGrid_PreviewMouseMove try to manage drag & drop operations. The left-click selection sets the "start" position, but the right-click action doesn't clear it. When a different entry is left-clicked, this is registering as a mouse move with the left button down, and since we have a start point registered it initiates a drag+drop op.
We need to clear the "start". A simple change to FileListDataGrid_PreviewMouseMove that discards the start point if the left button isn't down seems to solve the immediate problem, but fails in an even stranger way if the left-click on the directory was toward the right side of the filename field. The application gets a flurry of left button down events, some of them with negative coordinates, and concludes that the user is trying to drag & drop a directory into itself (failing with "cannot move a directory into itself or a descendant").
It seems that canceling out of a right-click context menu by clicking in the file list is causing WPF to freak out and generate bogus events. The code is using e.GetPosition(null) on a MouseEventArgs, and it looks like the null is leading to trouble. It's using the wrong element(s) as the root for the position calculation, and changes its mind on repeated calls, so a single mouse click event appears to be jumping all over the place. Replacing null with this (for the main window) seems to eliminate the weird events.
Update: this isn't sufficient unless you're careful not to move the mouse at all when you left-click to dismiss the context menu. The problem is that the mouse-move callback doesn't fire while the context menu is up, so all we see is a left click on one item and then a left click on a different item, with no events in between if the mouse moves at all, the distance between the first and second items is enough to initiate a drag.
If we clear the start position in FileListContextMenu_ContextMenuOpening, the issue stops happening.
I would feel bad about patching it up like this if the drag & drop handling wasn't one giant kluge to begin with.
fadden
commented
2 months ago
Steps to reproduce:
The application is treating this as a drag & drop operation, and moves the file into the subdirectory.
The issue seems to be with the way
FileListDataGrid_PreviewMouseLeftButtonDownandFileListDataGrid_PreviewMouseMovetry to manage drag & drop operations. The left-click selection sets the "start" position, but the right-click action doesn't clear it. When a different entry is left-clicked, this is registering as a mouse move with the left button down, and since we have a start point registered it initiates a drag+drop op.We need to clear the "start". A simple change to
FileListDataGrid_PreviewMouseMovethat discards the start point if the left button isn't down seems to solve the immediate problem, but fails in an even stranger way if the left-click on the directory was toward the right side of the filename field. The application gets a flurry of left button down events, some of them with negative coordinates, and concludes that the user is trying to drag & drop a directory into itself (failing with "cannot move a directory into itself or a descendant").It seems that canceling out of a right-click context menu by clicking in the file list is causing WPF to freak out and generate bogus events. The code is using
e.GetPosition(null)on aMouseEventArgs, and it looks like thenullis leading to trouble. It's using the wrong element(s) as the root for the position calculation, and changes its mind on repeated calls, so a single mouse click event appears to be jumping all over the place. Replacingnullwiththis(for the main window) seems to eliminate the weird events.Update: this isn't sufficient unless you're careful not to move the mouse at all when you left-click to dismiss the context menu. The problem is that the mouse-move callback doesn't fire while the context menu is up, so all we see is a left click on one item and then a left click on a different item, with no events in between if the mouse moves at all, the distance between the first and second items is enough to initiate a drag.
If we clear the start position in
FileListContextMenu_ContextMenuOpening, the issue stops happening.I would feel bad about patching it up like this if the drag & drop handling wasn't one giant kluge to begin with.