Version: 2.5 (using Devel) OS: Linux see below Reproducible: Sometimes Steps to Reproduce: 1. click on a track on the collection 2. drag to playlist Actual Results: - nothing happens, or - the mouse cursor gets a red cross sign (meaning drop not allowed) or - kde thinks, you dropped it to a different application. For instance: The track starts playing in a browser or a file transfer in kopete is triggered... very odd Expected Results: add to amarok playlist This happens in my current software setting very frequently. Sometimes I have similar probls when using drag'n'drop in kmail for moving emails around. So I think, this is actually a problem in kdelibs or even qt (4.8.0).
This is definitely a problem with kdelibs as it is only reproducible with KDE 4.8 beta
ok, just had the odd issue, that trying to move some email in kmail from one imap folder to another ended up in dropping them into one directory as I had a konsole window open... this can actually lead to data loss: the emails are moved out from kmail and (hopefully) appear somewhere else.
Indeed, this is a very annoying regression.
Myriam, are you running the same Qt version when reproducing with KDE 4.7 and KDE 4.8? There is actually no code in KDE that affects dragging; it is handled by Qt code.
Yes, in both cases the Qt version is 4.7.4, this only appeared with the change to KDE 4.8 beta and persists with RC1
Same problem in Clementine which is afaik qt4-only, no kde deps. Thus, its a qt problem?
I can confirm the problems, it even exists with dolphin which is not able to drag'n'drop items to its sidebar. This seems to be an upstream Qt issue.
*** Bug 291130 has been marked as a duplicate of this bug. ***
Raising severity as this can lead to a potential data loss.
*** Bug 291050 has been marked as a duplicate of this bug. ***
(In reply to comment #5) > Yes, in both cases the Qt version is 4.7.4, this only appeared with the change > to KDE 4.8 beta and persists with RC1 For the record, updating to Qt 4.8.0 does not improve the situation (tested with kmail2 as described in duplicate bug 291050), drag'n'drop still does not work. Just the mouse pointer flickering with fast motion seems to be gone.
I do think that the same problem happens with ark and drag and drop with dolphin. https://bugs.kde.org/show_bug.cgi?id=290697 This bug start to spread on many applications: amarok, clementine, kmail, dolphin and ark. At least the severity has been update but the priority should also be updated. Oh by the way the problem is not "sometimes" but always. With amarok a drag and drop from a bunch of files (if you have only one application amarok open) is to create a bunch of plasmoid link to each files selected on a desktop (not necessarly the one where amarok is located). If you have an application open in a desktop the files can be drop inside and so be open with this application). A very strange bug and, for my point of view, with a priority too low.
It's not a problem with kdelibs or with qt, but with kwin! Proof: * start kontact in a kde session -> dnd not working * log out, log in using fvwm * start kontact in a fvwm session -> dnd works perfectly * log out, log back into kde/plasma/kwin * start kontact -> dnd not working * keep kontact running, run in konsole "fvwm --replace" * -> dnd works perfectly * run in konsole "kwin --replace" * -> dnd not working Hope this helps finding the problem... :)
In addition, this seems to be related to desktop effects somehow. * DND not working * Disable desktop effects with Shift-Alt-F12 * Problems with re-drawing the screen, but once I've found the kontact window again, DND is working * Enable desktop effects again with Shift-Alt-F12 * DND is still working!!! (at least until now)
(In reply to comment #14) > * DND is still working!!! (at least until now) ... and stopped again, for no apparent reason. :|
Reassigning, see comment #13.
a) What's your focus policy? ("kcmshell4 kwinoptions", 1st tab) b) remove the window decoration (alt+f3/advanced) - still an issue?
Hi I can confirm #14. Switch off kwin effects, DnD in amarok works. ad #17a) My focus policy is "Click to focus" ad #17b) decoration removed, issue persist
(In reply to comment #17) > a) What's your focus policy? ("kcmshell4 kwinoptions", 1st tab) > b) remove the window decoration (alt+f3/advanced) - still an issue? a) "Aktivierung nach Klick" = "Click to focus" I guess b) yes, issue persists
fwiw, having tried to reproduce this issue, i have found that i can reproduce this with folderview on the desktop when compositing is on. when folderview is used as the desktop layout (easiest way to trigger this i've found), dragging a file from folderview to itself (iow, moving an icon with the mouse from one place on the desktop to another) will often not work. interestingly, there will be zones on the screen where it will work, but many areas of the screen will simply not work. and indeed, it will open it in a "random" window (e.g. it just opened a text file i dragged in a rekonq window that existed on a different virtual desktop). BUT! and here's the good news -> i know how to trigger the behaviour. all works well ... until i open kickoff. or, indeed, any popup applet. perhaps this has to do with unmanaged windows? these dialogs have window flags set thusly: dialog->setWindowFlags(Qt::FramelessWindowHint | Qt::WindowStaysOnTopHint | (gWidget->windowFlags() & Qt::X11BypassWindowManagerHint)); KWindowSystem::setState(dialog->winId(), NET::SkipTaskbar | NET::SkipPager); hth as at least now a triggering condition is found.
and i've found one more interesting thing -> drag and drag will still work on the desktop in areas where no window, on any virtual desktop, overlaps. if there is even one window overlapping a space (regardless of the virtual desktop it is on), then the drag enter and subsequent drop is sent to that window. if there are no windows that overlap a diven area of the desktop, then icons in folderview will happily relocate there (meaning the drop does get made to folderview)
problem disappears when "Keep window thumbnails" is set to "Never" in the Advanced tab of the Desktop Effects control panel.
Given Aaron's testing results I assume that our stacking order is broken. Windows from other desktops seem to be in front of the desktop. @Thomas: any idea or could it be that we hit an X limitation?
I doubt it's about order but there's obviously sth. in the way which is either the minimized (but not unmapped) window itself (while it iirc should be moved out of screen) or the input window isn't unmapped - xprop will tell me in about 30 minutes ;-)
- Is anybody being affected by this using the nvidia blob? - Is anybody being affected by this using the native graphicssystem by default?* - Does regular mouse input on the clients (anything but DnD) still just work as expected? - I doubt the hidden window is in the way, but could somebody please attach a dump of "xprop" and "xwininfo" on an affected client? (cursor turns into a cross -> click the window. You can redirect the output into a textfile "xprop > props.txt" / "xwininfo > infos.txt" * Ubuntu users and users of Qt 4.8: you do NOT unless you explicitly enabled configured it. Anybody else likely is, but possibly for plasma-desktop. It's probably needless to say that i could not reproduce this (changed deco to oxygen, tried plasma, dolphin and kwin with raster and native graphicssystem**, crowded other desktops with kde applications, notably kwrite, and opened kickoff on all related desktops, ensured dolphin was not raised last (upmost in the stack) and DnD'd random links into the sidebar. No issue at all :-( * there seems btw a very uncool behaviour of plasma-desktop here, since apparently "kquitapp plasma-desktop" triggers a crashrestart, i had to kill -9 it in order to change the graphicssystem... might however be an issue with Qt 4.8 and the maaaany "D-Bus connection created before QCoreApplication" warnings from KApplication ultimately rasing a legally handled signal, no idea - didn't try, but kwin doesn't do this :-\
(In reply to comment #25) > - Is anybody being affected by this using the nvidia blob? Work desktop (grenadine): affected, using ATI fglrx > - Is anybody being affected by this using the native graphicssystem by > default?* How do I find out? > - Does regular mouse input on the clients (anything but DnD) still just work as > expected? Yes > - I doubt the hidden window is in the way, but could somebody please attach a > dump of "xprop" and "xwininfo" on an affected client? (cursor turns into a > cross -> click the window. You can redirect the output into a textfile "xprop > > props.txt" / "xwininfo > infos.txt" XdndAware(ATOM) = BITMAP _MOTIF_DRAG_RECEIVER_INFO(_MOTIF_DRAG_RECEIVER_INFO) = 0x6c, 0x0, 0x5, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x10, 0x0, 0x0, 0x0 _NET_WM_NAME(UTF8_STRING) = "E-Mail – Kontact" WM_CLIENT_LEADER(WINDOW): window id # 0x3400004 _NET_WM_PID(CARDINAL) = 9220 _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL _MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x3, 0x3e, 0x7e, 0x0, 0x0 WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST WM_NAME(COMPOUND_TEXT) = "E-Mail – Kontact" WM_LOCALE_NAME(STRING) = "de_DE.UTF-8" WM_CLASS(STRING) = "kontact", "Kontact" WM_HINTS(WM_HINTS): Client accepts input or input focus: True Initial state is Normal State. bitmap id # to use for icon: 0x3400018 window id # of group leader: 0x3400004 WM_NORMAL_HINTS(WM_SIZE_HINTS): user specified location: 111, 0 program specified location: 111, 0 user specified size: 1561 by 874 program specified size: 1561 by 874 program specified minimum size: 457 by 531 window gravity: NorthWest WM_CLIENT_MACHINE(STRING) = "grenadine" WM_COMMAND(STRING) = { "/usr/bin/kontact" } xwininfo: Window id: 0x3400012 "E-Mail – Kontact" Absolute upper-left X: 115 Absolute upper-left Y: 25 Relative upper-left X: 0 Relative upper-left Y: 0 Width: 1561 Height: 874 Depth: 24 Visual: 0x23 Visual Class: TrueColor Border width: 0 Class: InputOutput Colormap: 0x20 (installed) Bit Gravity State: NorthWestGravity Window Gravity State: NorthWestGravity Backing Store State: NotUseful Save Under State: no Map State: IsViewable Override Redirect State: no Corners: +115+25 -4+25 -4-151 +115-151 -geometry 1561x874-0+0 *** Note: it took some time after switching on desktop effects for the bug to reappear. I started opening more apps, also on different desktops, with no effect. What seems to have triggered it in the end was a gpg-agent passphrase popup! ***
(In reply to comment #26) > Work desktop (grenadine): affected, using ATI fglrx ok, but i actually wanted a positive reply (unless everybody here's using fglrx) > How do I find out? >> Ubuntu users and users of Qt 4.8: you do NOT unless you explicitly enabled configured it. Anybody else likely is, but possibly for plasma-desktop. You've either compiled Qt with that attribute (apparent defaults: 4.8 -> raster, 4.7 -> native, Ubuntu used it before) or set the "QT_GRAPHICSSYSTEM" env var ("env | grep QT_GRAPHICSSYSTEM") > XdndAware(ATOM) = BITMAP > _MOTIF_DRAG_RECEIVER_INFO(_MOTIF_DRAG_RECEIVER_INFO) = 0x6c, 0x0, 0x5, 0x0, > 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x10, 0x0, 0x0, 0x0 > _NET_WM_NAME(UTF8_STRING) = "E-Mail – Kontact" > ......... I assume you *did* click a kontact window?! :-) > effect. What seems to have triggered it in the end was a gpg-agent passphrase sounds interesting as it (likely) grabs the kbd while DnD grabs the pointer.
*** Bug 290697 has been marked as a duplicate of this bug. ***
I've also seen this effect. I'm using an Intel 945GM.
The workaround gave by Aaron https://bugs.kde.org/show_bug.cgi?id=289945#c22 is working but now I do have one panel that windows are supposed to be able to be above, going above the other windows every ~15/20 seconds. Oh by the way I do have the problem, I am using ubuntu with ppa package but Qt is 4.7.4 so it's not related to Qt 4.8 only. My graphic card is an Intel GM45. Mouse is working as usual but drag and drop.
I'm using nvidia binary blob 290.10 with GeForce 9600M GT/PCI/SSE2
(In reply to comment #27) > (In reply to comment #26) > > Work desktop (grenadine): affected, using ATI fglrx > ok, but i actually wanted a positive reply (unless everybody here's using > fglrx) > I have nvidia (290.10) and I'm affected. On Gentoo, the raster graphicssystem is used I think.
(In reply to comment #25) > - I doubt the hidden window is in the way, but could somebody please attach a > dump of "xprop" and "xwininfo" on an affected client? (cursor turns into a > cross -> click the window. You can redirect the output into a textfile "xprop > > props.txt" / "xwininfo > infos.txt" > As the application works as expected, except DnD, the output seems to be correct. Add there is not possible to do it when DnD is active. xwininfo: Window id: 0x3a0004d "Billy Joel - You May Be Right :: Amarok" Absolute upper-left X: 59 Absolute upper-left Y: 18 Relative upper-left X: 0 Relative upper-left Y: 0 Width: 1861 Height: 1182 Depth: 24 Visual: 0x21 Visual Class: TrueColor Border width: 0 Class: InputOutput Colormap: 0x20 (installed) Bit Gravity State: NorthWestGravity Window Gravity State: NorthWestGravity Backing Store State: NotUseful Save Under State: no Map State: IsViewable Override Redirect State: no Corners: +59+18 -0+18 -0-0 +59-0 -geometry 1861x1182-0+0 _NET_WM_ICON_GEOMETRY(CARDINAL) = 0, 0, 60, 38 _NET_WM_USER_TIME(CARDINAL) = 7718355 _NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_MINIMIZE, _NET_WM_ACTION_SHADE, _NET_WM_ACTION_MAXIMIZE_VERT, _NET_WM_ACTION_MAXIMIZE_HORZ, _NET_WM_ACTION_FULLSCREEN, _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_CLOSE _KDE_NET_WM_TAB_GROUP(CARDINAL) = 3 _NET_WM_DESKTOP(CARDINAL) = 2 _KDE_NET_WM_ACTIVITIES(STRING) = "e09c0167-8060-4ca7-a846-34c9a6d18986" _KDE_NET_WM_FRAME_STRUT(CARDINAL) = 4, 4, 21, 4 _NET_FRAME_EXTENTS(CARDINAL) = 4, 4, 21, 4 WM_STATE(WM_STATE): window state: Normal icon window: 0x0 _NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 60817810 _NET_STARTUP_ID(UTF8_STRING) = "0" _NET_WM_STATE(ATOM) = _NET_WM_STATE_MAXIMIZED_VERT, _NET_WM_STATE_MAXIMIZED_HORZ WM_WINDOW_ROLE(STRING) = "MainWindow" _KDE_NET_WM_USER_CREATION_TIME(CARDINAL) = 7574735 _NET_WM_ICON(CARDINAL) = Icon (16 x 16): ... Icons skipped ... XdndAware(ATOM) = BITMAP _MOTIF_DRAG_RECEIVER_INFO(_MOTIF_DRAG_RECEIVER_INFO) = 0x6c, 0x0, 0x5, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x10, 0x0, 0x0, 0x0 _NET_WM_NAME(UTF8_STRING) = "Billy Joel - Big Shot :: Amarok" WM_CLIENT_LEADER(WINDOW): window id # 0x3a0003c _NET_WM_PID(CARDINAL) = 8341 _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL _MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x3, 0x3e, 0x7e, 0x0, 0x0 WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST WM_NAME(STRING) = "Billy Joel - Big Shot :: Amarok" WM_LOCALE_NAME(STRING) = "cs_CZ.utf8" WM_CLASS(STRING) = "amarok", "Amarok" WM_HINTS(WM_HINTS): Client accepts input or input focus: True Initial state is Normal State. bitmap id # to use for icon: 0x3a00053 window id # of group leader: 0x3a0003c WM_NORMAL_HINTS(WM_SIZE_HINTS): user specified location: 0, 0 program specified location: 0, 0 user specified size: 1920 by 1200 program specified size: 1920 by 1200 program specified minimum size: 509 by 179 window gravity: NorthWest WM_CLIENT_MACHINE(STRING) = "nbmkyral-E6500" WM_COMMAND(STRING) = { "/usr/bin/amarok" }
ok, it's apparently not a driver speciality and *should* be reproducable here. until then: can please anybody with a more or less regular encounter of this try whether it holds for "kwin --graphicssystem native --replace&" as well?
(In reply to comment #34) > ok, it's apparently not a driver speciality and *should* be reproducable here. > > until then: can please anybody with a more or less regular encounter of this > try whether it holds for "kwin --graphicssystem native --replace&" as well? Kwin restarted, no change. Bug persist.
Created attachment 67744 [details] kwinrc Maybe some kwin setting is trigger it. To reproduce I need to have open konsole on one virtual desktop and amarok/clementine on another visrtual desktop. All applications are maximalized. When I minimalize konsole, DnD work correctly.
(In reply to comment #27) > > How do I find out? > >> Ubuntu users and users of Qt 4.8: you do NOT unless you explicitly enabled > configured it. Anybody else likely is, but possibly for plasma-desktop. > You've either compiled Qt with that attribute (apparent defaults: 4.8 -> > raster, 4.7 -> native, Ubuntu used it before) or set the "QT_GRAPHICSSYSTEM" > env var ("env | grep QT_GRAPHICSSYSTEM") ok this was 4.8 without any special measures, so I assume it's raster but befor updating from 4.7.4 to 4.8.0 I saw the same effect > > > XdndAware(ATOM) = BITMAP > > _MOTIF_DRAG_RECEIVER_INFO(_MOTIF_DRAG_RECEIVER_INFO) = 0x6c, 0x0, 0x5, 0x0, > > 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x10, 0x0, 0x0, 0x0 > > _NET_WM_NAME(UTF8_STRING) = "E-Mail – Kontact" > > ......... > > I assume you *did* click a kontact window?! :-) Yes.
It seams, it could depend on Virtual desktops configuration. I have 4 desktops, in 2x2 configuration. Amarok is on desktop 3, konsole on desktop 2. When I minimalize konsole on desktop 3, DnD in amarok works. When I maximalize konsole - DnD in amarok does not work. But, when I minimalize konsole on desktop 3 and open a another console on desktop 1, konsole seems to don't affect amarok on desktop 3. But my futher testing shows me, sometimes Min/Max konsole on desktop 3 has not effect, DnD works. But when does not works, minimalization of konsole on desktop 3 always help.
(In reply to comment #38) > It seams, it could depend on Virtual desktops configuration. > > I have 4 desktops, in 2x2 configuration. > > Amarok is on desktop 3, konsole on desktop 2. When I minimalize konsole on > desktop 3, DnD in amarok works. When I maximalize konsole - DnD in amarok does > not work. > > But, when I minimalize konsole on desktop 3 and open a another console on > desktop 1, konsole seems to don't affect amarok on desktop 3. > > But my futher testing shows me, sometimes Min/Max konsole on desktop 3 has not > effect, DnD works. But when does not works, minimalization of konsole on > desktop 3 always help. Yay, last two paragraphs should be konsole on desktop 2, not 3 :-(
(In reply to comment #25) > - Is anybody being affected by this using the nvidia blob? Home desktop (pinacolada): affected, using nvidia proprietary driver > - Is anybody being affected by this using the native graphicssystem by > default?* qt is 4.7.4 without special settings > - Does regular mouse input on the clients (anything but DnD) still just work as > expected? yes > - I doubt the hidden window is in the way, but could somebody please attach a > dump of "xprop" and "xwininfo" on an affected client? On a kontact-4.4.11.1 window: huettel@pinacolada ~/Gentoo/misc/kde/kde-workspace/kwin $ xprop _NET_WM_DESKTOP(CARDINAL) = 0 _KDE_NET_WM_FRAME_STRUT(CARDINAL) = 4, 4, 25, 4 _NET_FRAME_EXTENTS(CARDINAL) = 4, 4, 25, 4 WM_STATE(WM_STATE): window state: Normal icon window: 0x0 _NET_WM_STATE(ATOM) = _NET_WM_USER_TIME(CARDINAL) = 117808214 _NET_WM_ICON_GEOMETRY(CARDINAL) = 588, 1044, 290, 20 _NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_MOVE, _NET_WM_ACTION_RESIZE, _NET_WM_ACTION_MINIMIZE, _NET_WM_ACTION_SHADE, _NET_WM_ACTION_MAXIMIZE_VERT, _NET_WM_ACTION_MAXIMIZE_HORZ, _NET_WM_ACTION_FULLSCREEN, _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_CLOSE _KDE_NET_WM_TAB_GROUP(CARDINAL) = 4 _KDE_NET_WM_ACTIVITIES(STRING) = "0bb5b771-627c-4f5a-9676-942336c65929" _NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 56623709 _KDE_OXYGEN_BACKGROUND_PIXMAP(CARDINAL) = 0 _KDE_OXYGEN_BACKGROUND_GRADIENT(CARDINAL) = 1 _NET_STARTUP_ID(UTF8_STRING) = "0" WM_WINDOW_ROLE(STRING) = "MainWindow#1" _NET_WM_ICON(CARDINAL) = Icon (16 x 16): ░ ░░ ░ ░░ ░ ░ ░░ ░ ░ ░ ░░░ ░░░ ░ ░ ░░ ░ ░░ ░ ░ Icon (32 x 32): ░░░ ░ ░ ░ ░ ░ ░░ ░ ░ ░░ ░ ░░ ░ ░ ░ ░ ░ ░ ░░ ░ ░░░ ░ ░░ ░░░ ░ ░░ ░ ░░░ ░ ░░ ░░░ ░░ ░ ░ ░░░ ░ ░░ ░░ ░ ░░ ░ ░ ░ ░ ░ ░ ░ ░ ░ ░ ░░ ░ ░ ░ ░░ ░ ░░░ ░ ░░░░░ ░ ░░░ ░ ░ ░░░░ ░░ ░░ ░ ░ ░ ░ ░░ ░░ ░ ░░░░░░░ ░░░░░░░░░░░░░░░░░░░░░░ Icon (64 x 64): (I removed this manually) Icon (128 x 128): (I removed this manually) XdndAware(ATOM) = BITMAP _MOTIF_DRAG_RECEIVER_INFO(_MOTIF_DRAG_RECEIVER_INFO) = 0x6c, 0x0, 0x5, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x10, 0x0, 0x0, 0x0 _NET_WM_NAME(UTF8_STRING) = "E-Mail – Kontact" WM_CLIENT_LEADER(WINDOW): window id # 0x360012d _NET_WM_PID(CARDINAL) = 9986 _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL _MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x3, 0x3e, 0x7e, 0x0, 0x0 WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST WM_NAME(STRING) = "E-Mail ? Kontact" WM_LOCALE_NAME(STRING) = "de_DE.utf8@euro" WM_CLASS(STRING) = "kontact", "Kontact" WM_HINTS(WM_HINTS): Client accepts input or input focus: True Initial state is Iconic State. bitmap id # to use for icon: 0x3600140 window id # of group leader: 0x360012d WM_NORMAL_HINTS(WM_SIZE_HINTS): user specified location: 76, 22 program specified location: 76, 22 user specified size: 1749 by 957 program specified size: 1749 by 957 program specified minimum size: 404 by 293 window gravity: NorthWest WM_CLIENT_MACHINE(STRING) = "pinacolada" WM_COMMAND(STRING) = { "/usr/bin/kontact" } huettel@pinacolada ~/Gentoo/misc/kde/kde-workspace/kwin $ xwininfo xwininfo: Please select the window about which you would like information by clicking the mouse in that window. xwininfo: Window id: 0x360014a "E-Mail – Kontact" Absolute upper-left X: 80 Absolute upper-left Y: 47 Relative upper-left X: 0 Relative upper-left Y: 0 Width: 1749 Height: 957 Depth: 24 Visual: 0x21 Visual Class: TrueColor Border width: 0 Class: InputOutput Colormap: 0x20 (installed) Bit Gravity State: NorthWestGravity Window Gravity State: NorthWestGravity Backing Store State: NotUseful Save Under State: no Map State: IsViewable Override Redirect State: no Corners: +80+47 -91+47 -91-76 +80-76 -geometry 1749x957+76+22 huettel@pinacolada ~/Gentoo/misc/kde/kde-workspace/kwin $
(In reply to comment #34) > ok, it's apparently not a driver speciality and *should* be reproducable here. > > until then: can please anybody with a more or less regular encounter of this > try whether it holds for "kwin --graphicssystem native --replace&" as well? Does not change anything on qt-4.7.4, problem still exists
It seems that knotify is an important part of this. I have configured amarok to use knotify when song is changed. Before knotiffy window is shown, DnD works. After knotiffy window is shown, DnD does not work. My current setup. Four desktops: 1 2 3 4 Desktop 2 - konsole Desktop 3 - firefox Desktop 4 - amarok I have active desktop borders - I'm moving between desktops using mouse. Following always works for me: 1) Go to desktop 2 - konsole 2) Go back to desktop 4 - amarok 3) Check DnD - works 4) Amarok is playing - Move slider to the end of the song. 5) Wait till song is changed and knotiffy window is shown (and hidden) 6) Check DnD - does not work 7) Go to desktop 3 - firefox - and back 8) Check DnD - does not work 9) Go to desktop 2 - konsole - and back 10) Check DnD - Works! 11) Repeat again, but switch desktop 2 and 3 - firefox and konsole It seems like knotify somehow increase a priority of window on previously visited desktop. Going to this desktop fix it.
Just a note. All three applications are maximalized.
Ok, can finally confirm that (maximized) dolphin on one VD and amarok on another VD (which doesn't matter here) alongside plasma notifications for track changes (even while on the amarok VD) is a great and reliable way to break amarok DnD - only to be resolved by entering the Dolphin VD - now let's see "why" ;-)
FTR: the commits b470dad7955babd73c51346831d290bed6b6ae4d 49211d657d40166855d4392c22fb17e140f13d70 e6790a637f326aa43b0f8c27995c3813d7c06280 are NOT the culprits - means we'll really have to work on this one :-\
Created attachment 67763 [details] Fixing patch for quick fix / confirmation GOT IT! commit a55125b9dc1bd60e258dec133878c3da4178063d accidentally removed stacking handling of hiddenPreview windows alongside the dropped topmenu support, resulting in them being unhandled by xrestack, turning them on top. As a result only the input shaping prevents them from intercepting events and this is probably not supported by DnD - why this is predominantly triggered by those notifications windows, i still don't know - i condemn responsible master and/or padawan to figure that ;-)
Patch works for me, thanks.
I have also similar bug 291141 with the automatically hidden plasma panel. After some time, panel does not pop up, but I can see a yellow line on place where panel is. Restart of kwin fix this. The symptoms are similar - plasma react on mouse in the panel popup area, but panel is not shown because something is missing or incorrect. Again - after some time could mean after knotify, but I need to find out the real reason.
> I have also similar bug 291141 with the automatically hidden plasma panel. > After some time, panel does not pop up, but I can see a yellow line on > place where panel is. Restart of kwin fix this. This could be the same bug. As you have the patch applied just watch whether it still happens. If yes please report a new bug for it. If no, everything is fine :-)
Patch works for me too (so far, keeping fingers crossed) :)
I confirm your patch fixes the drag'n'drop issue for me! I applied it, recompiled KWin 4.8 branch and executed "kwin --replace". Tested: - d'n'd dolphin places (works now) - d'n'd KMail messages from list to folder (works now) - d'n'd Amarok title from media sources to playlist (works now). Overall, the issue seems to be globally fixed! Thx for your work.
Well, I've patch applied and hidden panel does not popup right now, so patch does not help. Why I need to report a new bug as the report already exists, it only needs to be re-assigned to kwin I think.
> Why I need to report a new bug as the report already exists, it only needs to be re-assigned to kwin I think. I expected that there is no bug reported for this issue and this should not be assigned to KWin - we are not the collection place for all window related bugs. This first has to be investigated in Plasma whether the bug is in Plasma or somewhere else.
(In reply to comment #52) > Well, I've patch applied and hidden panel does not popup right now, so patch > does not help. Why I need to report a new bug as the report already exists, it > only needs to be re-assigned to kwin I think. Plasma afaik (still) uses it's own electric border windows, being responsible to catch mouse crossings to show autohiding panels. If showing autohiding panels fails, that's due to those electric borders which need to be on top of everything -> plasma-desktop either fails to raise the border windows (they're override windows, what means the WM doesn't handle them at all, neither their screen position, nor their stack position) at all or raises them to an insufficient stack position Anyway. If the patch doesn't fix it (what is an a fully understood regression, i had no doubt about this and even posted the patch here before testing it locally) IT IS NOT THE SAME BUG and things (bugreports) collecting a bunch of random other things (other bugreports) are called "trashcan" and here just in the real world work the same - the content is ignored and at some point just dumped.
Git commit ff3d73601904414defccaf4434886cf1f94cab8a by Thomas Lübking. Committed on 13/01/2012 at 03:08. Pushed by luebking into branch 'KDE/4.8'. Fix regression igonring hiddenPreviews on stacking updates REVIEW: 103687 M +9 -0 kwin/layers.cpp http://commits.kde.org/kde-workspace/ff3d73601904414defccaf4434886cf1f94cab8a
Git commit c5c08d45e90e88ab36d49b20ba7f1cccba4a7019 by Thomas Lübking. Committed on 13/01/2012 at 03:08. Pushed by luebking into branch 'master'. Fix regression igonring hiddenPreviews on stacking updates REVIEW: 103687 M +9 -0 kwin/layers.cpp http://commits.kde.org/kde-workspace/c5c08d45e90e88ab36d49b20ba7f1cccba4a7019
(In reply to comment #54) > (In reply to comment #52) > > Well, I've patch applied and hidden panel does not popup right now, so patch > > does not help. Why I need to report a new bug as the report already exists, it > > only needs to be re-assigned to kwin I think. > > Plasma afaik (still) uses it's own electric border windows, being responsible > to catch mouse crossings to show autohiding panels. If showing autohiding > panels fails, that's due to those electric borders which need to be on top of > everything > > -> plasma-desktop either fails to raise the border windows (they're override > windows, what means the WM doesn't handle them at all, neither their screen > position, nor their stack position) at all or raises them to an insufficient > stack position > > Anyway. If the patch doesn't fix it (what is an a fully understood regression, > i had no doubt about this and even posted the patch here before testing it > locally) IT IS NOT THE SAME BUG and things (bugreports) collecting a bunch of > random other things (other bugreports) are called "trashcan" and here just in > the real world work the same - the content is ignored and at some point just > dumped. OK. Thanks for explanation. And thanks for the fix.
This bug is back in KDE 4.9.4 and Amarok 2.6.0 I am not able to drop tracks on the playlist. I have tried many of the workarounds mentioned in this bug (other than switching the window manager) but am not able to get it to work at all.
(In reply to comment #58) > This bug is back in KDE 4.9.4 and Amarok 2.6.0 No. Whatever you may experience, *this* bug, it is not. This was was introduced by a severe regression in kwin because some code got lost during refactoring. It's however still there since ;-) Please also notice that this bug would have affected may applications and is no way restricted to amarok or its playlist. > I have tried many of the workarounds mentioned in this bug (other than > switching the window manager) This would be the only way to confirm a bug in the WM at all. In case changing to eg. OpenBox resolves the issue, please file a new bug against kwin, otherwise file a bug against amarok. Thanks.