Bug 178679

Confirmed using current trunk r901297

*** Bug 188407 has been marked as a duplicate of this bug. ***

It seems that keyboard modifiers (Ctrl, Shift, Alt) are only taken into account correctly in drag&drop operations if both the drag source and the drop target belong to the same process (e.g., drag&drop between split Dolphin views, between two Dolphin windows, or between split views in a Konqueror window). It goes wrong if two different processes are involved.

The problem is that the line

Qt::KeyboardModifiers modifiers = QApplication::keyboardModifiers();

in KonqOperations::doDrop() always assigns 0 to 'modifiers' in this case. Looking at the Qt documentation, it seems that QApplication::keyboardModifiers() does indeed not always return the correct modifiers at the time the function is called:

http://doc.trolltech.com/4.5/qapplication.html#keyboardModifiers

It seems that it rather returns the state of the modifiers the last time a key was pressed or released inside the process receiving the drop event. This can have quite unexpected consequences: Try to press Shift or Ctrl while a Dolphin window has focus, click some other window (like Konqueror) before releasing, then drag a file from outside and drop it on the Dolphin window -> the file will be moved without asking.

I don't know if there is a simple way out of this problemr, or if we have to come up with some hack to resolve this, or if we should actually ask Qt Software to change this behaviour (it's not really a bug, I suppose, because the documentation says that it's like that)...

I just want to add that using QDropEvent::keyboardModifiers() rather than QApplication::keyboardModifiers() does not help, i.e., the simple patch below does *not* work.

Index: apps/lib/konq/konq_operations.cpp
===================================================================
--- apps/lib/konq/konq_operations.cpp   (revision 951225)
+++ apps/lib/konq/konq_operations.cpp   (working copy)
@@ -268,7 +268,7 @@
         }

         // Check the state of the modifiers key at the time of the drop
-        Qt::KeyboardModifiers modifiers = QApplication::keyboardModifiers();
+        Qt::KeyboardModifiers modifiers = ev->keyboardModifiers();

         Qt::DropAction action = ev->dropAction();

I'll add David to CC, maybe he has an idea how to solve this...

*** Bug 189697 has been marked as a duplicate of this bug. ***

I can confirm that this bug is still present in KDE 4.3 RC3.

*** Bug 228977 has been marked as a duplicate of this bug. ***

*** Bug 232823 has been marked as a duplicate of this bug. ***

*** Bug 228627 has been marked as a duplicate of this bug. ***

Yep, I know how to solve this: by doing just like we were doing in Qt3: asking the X server for the keyboard modifiers "right now", rather than asking Qt.
Proof-of-concept patch attached, fixes the problem -- but only on X11.

The problem is that the conversion from the native modifiers (on X11/mac/windows/symbian) to Qt::KeyboardModifiers appears to be non-trivial so this should really be done inside of Qt, which has internal code for such a conversion already. I'll have to make a merge request, but after getting help from mac and windows developers in order to provide a complete patch... this is going to be tricky.

Created attachment 43066 [details]
hack

OK, merge request for Qt done: http://qt.gitorious.org/qt/qt/merge_requests/585

If this goes in, it will be for Qt-4.7.

Nice work, David!

You're right that the behaviour of QApplication::keyboardModifiers() is as documented, such that a new static member should be added.

However, I think that QDropEvent::keyboardModifiers() should also be modified - the docs say that it "Returns the modifier keys that are pressed", and I think it's not unreasonable to assume that this is the case even for inter-process drag&drop operations.

Yep, actually #qt-labs came to the same conclusion: for fixing this bug, Qt should query the modifiers at drop event time and update the "currently known by qt" modifiers, i.e. QApplication::keyboardModifiers()   (which also makes QDropEvent return the right value).

I just made a second merge request, which has the fix for this:
http://qt.gitorious.org/qt/qt/merge_requests/590

The new API would be Qt-4.8-only, while hopefully this bugfix could go into Qt-4.6.3 and otherwise Qt-4.7, we'll see.

The merge request has been accepted for QT 4.7 and the problem doesn't occur with installed QT 4.7.0. Closing...

This happens again in Plasma 5.3 Frameworks Version 5.9.0 between folderview desktop and Dolphin Version 15.04.0 using KDE Development Platform 4.14.7.