Dragging a Firefox to the desktop (so it creates a new Firefox window for it) doesn't work. Tested in both Folder and Desktop layout, it thinks you want to add something like a folder or a file instead: http://i.imgur.com/PcE31Yt.png Weird thing is that if you drag and drop the tab extremely fast it actually works an intended, but if you take a few milliseconds longer it does as stated above.
I can confirm this
Mime data from a Firefox tab: application/x-moz-tabbrowser-tab text/x-moz-text-internal the next question is why we blindly think we accept a mimetype like that.
It's a regression from plasma-4, confirming it's still there with 5.2.2
Workaround (and maybe an explanation for the "weird thing" in the initial report): dragging a tab onto the body of the Firefox window causes a new window to be created with the tab in the new window. That is, dragging to the desktop fails, but dragging to Firefox itself has the same effect as desired by dragging to the desktop.
*** Bug 357793 has been marked as a duplicate of this bug. ***
Still present on KDE Neon 5.7.2, Frameworks 5.24.0. I asked a question about this bug in the forum a couple of days ego. https://forum.kde.org/viewtopic.php?f=309&t=135028 "Locking Widgets" is a workaround of sorts to this one.
Can confirm - the issue is reproducible in: Distribution: KDE neon Developer Edition - Stable Branches Plasma: 5.11.4 Frameworks: 5.41.0 Qt: 5.9.3 Kernel 4.10.0-40-generic Type: 64-bit
Git commit ab007182ad3e5c890aa4e6cfaacfddc575c46e95 by Kai Uwe Broulik. Committed on 09/01/2018 at 14:26. Pushed by broulik into branch 'master'. [Desktop Containment] Explicitly reject Firefox tab drops This is a real-world fix for a long-standing issue. Mime-type determination and everything is asynchronous, so we cannot know in advance whether to accept or reject the drop. FIXED-IN: 5.12.0 Differential Revision: https://phabricator.kde.org/D9640 M +6 -0 containments/desktop/package/contents/ui/main.qml https://commits.kde.org/plasma-desktop/ab007182ad3e5c890aa4e6cfaacfddc575c46e95