Opened 14 hours ago
Last modified 6 hours ago
#19368 new bug
During a in-app drag and drop, the Tracker ignores the drag message and only considers the selection of the source window
| Reported by: | Nexus-6 | Owned by: | nobody |
|---|---|---|---|
| Priority: | normal | Milestone: | Unscheduled |
| Component: | Applications/Tracker | Version: | |
| Keywords: | Cc: | ||
| Blocked By: | Blocking: | ||
| Platform: | All |
Description
When a file is dropped in-app, i.e. from one window to another (this also applies to the Desktop), the Tracker looks for the current selection in the source window and if the selection is empty it returns doing nothing. Worse still it does not even check if the selection matches with the refs and just picks up the selected file from the source window ignoring the actual refs in the message.
This leads to many side effects.
Scenario A
Take two Tracker windows side by side pointing to folderA and folderB, respectively. While dragging whatever element from windowA to windowB, close the former with the shortcut CMD-W. Now that it’s gone, keep dragging and drop the file onto the destination window and the Tracker will… do nothing.
Scenario B If the selection is changed “in-flight” with the arrow keys the new currently selected element is moved to the destination.
For a more comprehensive context, see this post https://discuss.haiku-os.org/t/drag-a-message-with-a-designated-bmessenger-aka-codename-dropit/15933/21.
