Bug 267188 - Drag and drop to move and now in drag select mode despite releasing mouse
Summary: Drag and drop to move and now in drag select mode despite releasing mouse
Status: RESOLVED FIXED
Alias: None
Product: dolphin
Classification: Applications
Component: general (show other bugs)
Version: 16.12.2
Platform: Ubuntu Linux
: NOR major
Target Milestone: ---
Assignee: Peter Penz
URL:
Keywords: needs_verification, usability
Depends on:
Blocks:
 
Reported: 2011-02-26 06:02 UTC by Lee Dunbar
Modified: 2012-12-11 23:09 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.8.0
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Lee Dunbar 2011-02-26 06:02:34 UTC
Version:           unspecified (using KDE 4.5.1) 
OS:                Linux

Start in a window with files and folders visible, with folder expansion enabled.
Split the view, navigate to a folder on a different drive.
Return to the first pane and click the icons of the files and/or folders.
Click several items to add to the group of selected items.
When you are done selection, click and hold on one of the selected items.
While holding the selection by the one item you are clicked on, drag the items into the opposite part of the split.
Release the mouse button.

On my system (Celeron D, Logitech Trackman Wheel, Kubuntu 10.10 64  AND also Kubuntu 10.04 with an earlier KDE 4.x), this produces an error 90% of the time.

The error is that I am now quite stuck in an unintended drag selection mode: I'm doing a rubber band selection in the source portion of the split. I can't simply release the mouse button to stop dragging because I already released it to drop the items in the destination window, I'm not holding the mouse button.

Footnote: I usually make several user preference settings before I ever start using Dolphin, so this might be settings dependent. Contact me if you want a file, just tell me the absolute reference to the file and it is yours!

PS: 

Reproducible: Didn't try

Steps to Reproduce:
Open Dolphin;
split the window;
make one split display another directory;
click select several files and/or folders;
click and drag these into another split of the same parent window of one session of Dolphin;
release the selected items, select either move or copy, no difference.

Actual Results:  
After releasing, move your pointer back across to the source split;
watch the drag select box make selections while you are not holding a mouse button.

Expected Results:  
absolutely nothing should be happening. The selection should respond as per user selection (items being moved should eventually show no more selections after progress completes or copy should leave the selection as they were before dragging).

To completely perform this action, you see that you must release the mouse button. The response of Dolphin is as if you were still pressing the mouse button. Therefore, the mode of clicking and using any additive build up of a selection is a mode that needs to cancel the drag selection mechanism in software. One *possible* opportunity to cancel the drag selection internally MIGHT be to defeat the drag selection when I click the menu to decide to move or copy. When that menu appears, the list of items has been decided by the user, so the selection function needs to cease adding to the selection (with the error, the selection mechanism remains activated). The visual representation of the selected items is not the issue, the function of selecting more files needed to end somewhere around the step when the menu asks the user how to act on the selection.

When the drag selection is in operation, the user can do nothing simple to cancel the mode: escape key does not stop the drag selection, alt+escape seems as useless as plain escape, and control+escape is mapped to raising the System Activity monitor. Even then, the mode should never have started.

Possible data loss if you do NOT see right away that the drag selection is in operation. Users might also not know it happens at all.
Comment 1 Lee Dunbar 2011-02-26 06:08:22 UTC
Sorry, missed the drop down for reproducibility. Over 90% reproducible.
Comment 2 Frank Reininghaus 2011-02-27 14:21:42 UTC
Thanks for the bug report. I could not reproduce the problem so far. Some questions:

1. You say that you have expandable folders enabled. Is it important that the selected items are in an expanded folder? Maybe a screenshot might help to make it clear what kind of setup is required to reproduce the bug.

2. You wrote that you click the items to select them. Do you use the "double click to open files and folders" mode (such that a single click selects an item), or do you select the items by clicking the "+" (selection marker) or using some other method?
Comment 3 Lee Dunbar 2011-03-01 20:21:03 UTC
@frank

1] No, for the errors which I experience, it is unimportant whether or not I select from one folder or from many.
2] I reconfigure Dolphin to use single click mode within the first 5 minutes with any installation of Dolphin; single click is my preferred mode of operation. I believe that I've seen the drag selection problem under double click, but I have such greater experience with single click that I'm not totally certain.

note: once this error mode begins, the split where it is occurring as actually actively selecting items, so a screen shot after the problem begins will not show the selected files that began the problem mode.

added note: I can also click and click and drag my selections from within Dolphin to an external window (a Macintosh emulator which supports drag and drop, not just a second instance of Dolphin) and then have the drag selection error become a problem. First time experiencing that mode was late yesterday.

One solution to end this error mode of drag selection is to close the split where the erroneous drag selection is in effect, but I'd prefer that I would not need to work around the problem this way.
Comment 4 Lee Dunbar 2011-03-07 04:06:03 UTC
Possibly relevant: https://bugs.kde.org/show_bug.cgi?id=267850
Comment 5 Lee Dunbar 2011-03-11 13:44:39 UTC
https://docs.google.com/uc?id=0B7z5Lgtcb2qXZGE3YWExNjItYWIwMC00YjEzLWEyOTgtMGEzMDc3YTQ5MjFi&export=download&authkey=CO-c-eQM&hl=en

NOTE! Please download the video, the Google flash player cannot play it properly.

After dragging a single file from left pane, into a window that is now minimized, I see the drag function is in force.
I then
-I clicked and launched Synaptic,
-clicked a few times to set up search, select files,
-clicked to install that programs.
I left Synaptic as the last active application, I then launched the video recording program, and captured the drag problem.

Notice how I stated at each step that I have clicked and released the left mouse button AFTER the drag selection was already in force - other applications see that I released the mouse button, the trackman wheel left mouse button is not mechanically sticking!

HTH
Comment 6 Todd 2011-04-02 18:37:56 UTC
I get this all the time, but not only in the mode you describe, it also happens in icon mode even without split view.  It is usually triggered when dragging stuff to a tab, then releasing.  I still get the rubber band.  So although your method can trigger it, it seems it can be triggered whenever you drag then release outside of the current file view.
Comment 7 Frank Reininghaus 2011-04-03 10:55:59 UTC
I'm sorry, but I still can't reproduce the problem in master.

(In reply to comment #5)
> After dragging a single file from left pane, into a window that is now
> minimized, I see the drag function is in force.

Lee, you say you're dragging to a window that is now minimized. Is that another Dolphin window or another application? Do you drop the files in that window?

(In reply to comment #6)
> It is usually triggered when dragging
> stuff to a tab, then releasing.  I still get the rubber band.

I can't reproduce that either. How do you select the stuff before you're dragging it to the tab?
Comment 8 Darren Edale 2011-04-04 13:24:18 UTC
This happens for me very frequently (guess 90%+ of the time I drag and drop), and has done for over 12 months in all versions of Dolphin I have used in that time. Turning off desktop compositing vastly reduces the chances of it occurring (I've not been able to trigger it without compositing enabled for the last few hours). On my system, in order to trigger this problem, any drag-and-drop operation will do:

1. open dolphin
2. split the view so that there are two panes
3. make the two panes show different locations. my destination pane for the drag-and-drop is usually a "sftp" url but it occurs with local paths as well
4. make both panes use "details" view
5. click and hold on any file in the source pane
6. drag that file to the destination pane
7. release the mouse button and choose "copy" or "move" (either will do)
8. move the mouse back over the source pane
9. when the mouse pointer is in what would be considered a "scroll zone" for the source pane (i.e. close to the edge of the pane) if a drag were in progress, despite the fact that the drag and drop operation is completely finished, the source pane will scroll as if the drag is still ongoing

Although this behaviour does not occur 100% of the time, when it does occur it is remarkably persistent. For example, after completing a drag-and-drop operation, then moving the Dolphin window then resizing the Dolphin window, the source pane will still scroll with the mouse pointer in the "scroll zone" even though the mouse button has been pressed and released several times since the drag finished.

My subjective experience also is that Dolphin's file view can be quite unresponsive on my system (again, with compositing enabled), much less responsive than Krusader, and my initial gut feel was that it was this perceived unresponsiveness that was causing the problem - or at least that the two had the same root cause. For example, when hovering the  mouse over file entries, the hover effect (highlighting the background of the file name under the mouse pointer) takes a few tens of ms to catch up with the mouse - it's a little like the "pointer trails" or "ghost" effect we used to have for the mouse pointer (is that even still available?). Similar lags are experienced when clicking files and performing other common operations.

My feeling is that there may be something akin to a race condition occurring when compositing is enabled. My (non-scientific) feeling is that with compositing enabled the scrolling that occurs when dragging into the scroll-zone of a pane sometimes does not complete before the drag operation completes. That is, the file is dragged to the edge of its source pane, triggering the source pane to scroll. While this scrolling is occurring, the user completes the drag and the file is dropped onto its destination. For some reason, it seems as if this prevents the source pane from exiting its "scrolling because the user has dragged a file into my scroll zone" state. Without compositing enabled, scrolling is much smoother and it appears as if the triggered scroll completes very quickly - certainly more quickly that the user can complete the drag-and-drop operation. I'm not sure if this assessment is accurate or even helpful, but it's what I think I would be looking to confirm or refute if I were the author of the app that's exhibiting this behaviour under these circumstances.

It could, of course, be that the behaviour I'm reporting is a different "bug" as nobody else has mentioned compositing.

My system is:

Acer Extensa 5620
Core 2 Duo T5250 @ 1.5GHz
ATI Mobility Radeon HD 2400XT
3GB 800MHz RAM
Kubuntu 10.10
kernel 2.6.35-28
KDE Platform 4.6.1
Dolphin v1.6.1
External 1920x1280 display (also occurs on built-in 1280x800 display)
External wireless USB mouse and keyboard (also occurs using trackpad and built-in keyboard)
Desktop compositing is enabled, Oxygen animations (System Settings -> Application Appearance -> Style -> Applications -> [Widget style = Oxygen] Configure... -> Enable animations) are not

Dolphin settings
Display Modes -> Details -> Icon Size -> Default is at lowest level
Display Modes -> Details -> Icon Size -> Preview is one notch above lowest level
Display Modes -> Details -> Font is "System Font"
Display Modes -> Details -> Expandable folders is ticked

Navigation -> Double-click to open files and folders is selected
Navigation -> Open archives as folder is ticked
Navigation -> Open folders during drag operations is ticked

General -> Behaviour -> Remember view properties for each folder is selected
General -> Behaviour -> Ask for confirmation when -> Moving files or folders to wastebin is NOT ticked
General -> Behaviour -> Ask for confirmation when -> Deleting files or folders is ticked
General -> Behaviour -> Ask for confirmation when -> Closing windows with multiple tabs is ticked
General -> Behaviour -> Rename inline is ticked
General -> Behaviour -> Show tooltips is ticked
General -> Behaviour -> Show selection marker is ticked
General -> Behaviour -> Natural sorting of items is ticked

If you need to know other settings, just ask.
Comment 9 Lee Dunbar 2011-04-23 20:27:12 UTC
frank: re: comment 7:

First question: to any window which accepts the grouping (in my case, an emulator window which accepts files as disk images and to another dolp[hin window).

Second question: error occurs either way: drag to select a group has failed when I tried it, but I normally click the icon of each file and each folder that I wish to move - this refers to the selection method where hovering the pointer over a file or folder ICON activates the green plus sign or red minus sign, then click the plus or minus sign. After deciding you have selected enough of a mix of files and folders, click down on a selected item (at this point I usually click the file/folder NAME), then drag them to the destination window.

At this point, I begin to wonder if this might be a conflict with... something that ... tries to get a large amount of info based on what my grouping consists of. This wimpy theory assumes that the conflicting executable needs a lot of time to read the data from the Dolphin event. Naturally, if this were the case, then fewer files in the selection OR slower drag time would alleviate the error.
Comment 10 Frank Reininghaus 2011-07-02 13:10:59 UTC
I'm seeing this bug sometimes now (with Dolphin from OpenSuse 11.4's 4.6 packages), in the situation described in comment 8. Unfortunately, I haven't found out yet how to trigger the bug reliably.
Comment 11 Johannes Georgi 2011-07-20 00:04:50 UTC
I have this bug too, kde 4.4.3 with dolphin 1.4, only with columns view, don't know how to reproduce but happens very often.
Sometimes the "selecting" only starts after hovering one or two seconds over the dolphin window again after the drag.
It seems to me that in some conditions the mouseUp doesn't get through to dolphin, I think the "select" starting position is always the starting position of the original drag.
Comment 12 Lee Dunbar 2012-12-11 23:09:56 UTC
Dolphin 1.7, KDE 4.7.4: Drag selection issue HAS reoccurred exactly ONE time, where in Dolphin 1.4, I would have expected maybe 20 events thus far. Sorry I even had one event to report, but reasonably, I cannot reproduce aside from using Dolphin as I always use it (described above), and with only one event in all that time, I'd not expect any replies nor any efforts. Good work fixing the vast majority of my events with Dolphin 1.7.