Bug 339399

Summary:	Using Drag and drop with ALT+Tab only works on some applications. Why: ALT key behavior in dolphin.
Product:	[Applications] dolphin	Reporter:	Marco Silva <marco_silva85>
Component:	general	Assignee:	Dolphin Bug Assignee <dolphin-bugs-null>
Status:	CONFIRMED ---
Severity:	normal	CC:	arjunak234, fabian, mail, oded
Priority:	NOR
Version:	4.14.0
Target Milestone:	---
Platform:	Arch Linux
OS:	Linux
URL:	https://code.google.com/p/chromium/issues/detail?id=42494
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description Marco Silva 2014-09-25 23:01:59 UTC

When dragging a file, if you ALT+Tab to the target aplication then drop the file, it will not work (in many applications).
This happens because while dragging, dolphin identifies the ALT key as a modifier for creating a link to the file (instead of the normal behavior). You can see the cursor icon changing when you press ALT while dragging. The cursor icon goes back to normal when you release ALT.
However, if you do ALT+TAB instead (and don't release the file yet), when you release ALT, the cursor doesn't go back to the normal behavior - you can try to press ALT more times, it won't do a thing.

Fix: Either really fix this issue (ALT release out-of-dolphin behaving correctly) or, if technically not possible (because of X11 for example), add an option to modify the keyboard shortcut from ALT to another one (or remove).
This bug was already experienced by some users:
https://code.google.com/p/chromium/issues/detail?id=42494
they thought it was a problem of the application which you are dropping the file.
Comment #16 identifies correctly the issue with dolphin and explains the above.

Reproducible: Always

Steps to Reproduce:
1. Drag a file
2. ALT+TAB
3. Release the file inside chromium / ark archive / sublime / other affected applications (Firefox is not affected for example)

Actual Results:  
Application is unable to open the dragged file.

Expected Results:  
Application able to open the dragged file.

Comment 1 Arjun AK 2014-09-26 05:19:02 UTC

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

Comment 2 Marco Silva 2014-10-01 11:07:31 UTC

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

Comment 3 Frank Reininghaus 2014-10-05 08:53:41 UTC

Thanks for the bug report! It seems that this might be a problem that has been reported already (bug 210847).

(In reply to Marco Silva from comment #0)
> Comment #16 identifies correctly the issue with dolphin and explains the
> above.

Actually, I think that this might be a problem in Qt, which we can do nothing about inside Dolphin.

> Fix: Either really fix this issue (ALT release out-of-dolphin behaving
> correctly) or, if technically not possible (because of X11 for example), add
> an option to modify the keyboard shortcut from ALT to another one (or
> remove).

To my knowledge, there is no code in Dolphin or any other part of kdelibs which reacts to keyboard modifiers (such als Alt) while an *outgoing* drag operation is in progress.

Comment 4 Fabian Vogt 2016-08-20 16:53:50 UTC

I have the same issue here, if the cursor does not move after Alt-Tabbing to a different application, the drop target is the wrong window.
I tested both dolphin 16.04.3 and gwenview 16.04.3 as source, so it's likely not dolphin-specific.

Comment 5 Julian Steinmann 2018-05-17 19:35:19 UTC

I can still confirm this issue with Dolphin 18.04. Probably a Qt bug, because @Fabian also experienced the bug with Gwenview.

Comment 6 Oded Arbel 2020-08-21 18:58:25 UTC

I cannot reproduce this issue on my system with Plasma 5.19.80 (neon developer edition), frameworks 5.74.0, QT 5.14.2: when ALT-TABing, as long as I keep ALT pressed, the drag cursor shows the link badge, but as soon as ALT is released (which you can kind of have to do to get the application switcher to actually switch to the target application) then the drag cursor goes back to the default behavior and copy works well.

If there was an issue with Qt, it must have been fixed before 5.14.2.