Basically, this is this bug: https://bugs.kde.org/show_bug.cgi?id=351014 ... but windows keep slowly wandering downwards instead of upwards. Which - I must admit - is a big improvement, since it means I have a lot of time before the title bar disappears from the screen. But still, I'd prefer if they stayed where they are ... This seems to happen mostly after / during kwin crashes / freezes. Have not been able to reproduce it reliably by manually restarting kwin or switching to TTY and back, but over the course of the day, my corner-tiled windows keep slowly and steadily wandering down the screen and I keep having to go through all of my desktops to drag them back. Can't tell for sure how long this has been going on; it only started to become a really obvious / annoying problem recently due to the frequent random crashes / freezes. Reproducible: Sometimes Steps to Reproduce: 1. Quick tile windows to corners 2. Wait. ??? maybe happens during random kwin_x11 freezes / crashes Actual Results: Windows slowly keep wandering down the screen over the course of the day. Expected Results: Windows should stay where they are.
Took a while longer than it should have, but I just noticed that: 1) I can reliably reproduce this after all with "killall kwin_x11 -9; kwin_x11&". Always seems to happen with -9. 2) It does not only affect corner-tiled windows (any more?). Seems to have been random that none of the (few) other windows I had open were affected before.
don't kill kwin with -9. Please use kwin_x11 --replace which does not run into weird conditions. Even a normal kill should work properly, just don't use -9. Setting to INVALID as the move down is caused by the kill -9.
kill -9 is just a way to reproduce the bug without having to wait for random occurrences. It happens several times per day without me killing kwin - sometimes after crashes, sometimes after hibernation, sometimes just for no apparent reason, maybe when I'm switching TTYs In addition to that, "move all windows downwards" isn't really part of the description of the -9 kill signal and I have been unable to reproduce the bug in the 5 other window managers I tested.
(In reply to unsuspicious.fakename+kdebugs from comment #3) > kill -9 is just a way to reproduce the bug without having to wait for random > occurrences. It happens several times per day without me killing kwin - > sometimes after crashes, sometimes after hibernation, sometimes just for no > apparent reason, maybe when I'm switching TTYs This is not normal. Sorry to say so. But KWin shouldn't crash. Not once and clearly not several times a day. If you hit crashes, please report them so that we can fix them and don't have to workaround the moving windows problem.
The crashes and freezes are unrelated issues (probably both upstream: crashes could be kernel, freezes nvidia; don't know yet) and as far as I can tell they aren't the (root / only) cause of the window position problem, they just lead to it happen much more frequently. I have not been able to account for the cause of the window position change every time it happened, but the crashes / freezes can happen without "window bug" and the other way around.
This does *only* affect "quick tiled" windows, right? What's the state after this happens (window still quick tiled, ie. dragging it away from the corner restores some size)? NB: this *only* matters if the problem did NOT occur for a kwin restart (after kill/segfault/etc.) for the quick tiled state is then lost for sure. Also, which decoration do you use? ---- On a general remark, please stop killing -9 unless you really know that you want it. -15 is the default (SIGTERM) and should be sufficient, you can provoke "segfaults" w/ -11 (SIGSEGV) You can also use symbols ("kill -l" for a list) SIGKILL means that the kernel removes the process and is really about the worst of all choices for nothing in the process (incl. libGL) has even a remote chance to do some cleanup to leave behind a sane context.
Oh... I only had quick tiled windows... is resizing them all a bit enough to test if it happens to other windows? If so, then: Most normal windows except for maximized ones seem to be affected (at least when I trigger it with kill -9. I'll leave some windows floating around to see if behaviour is the same when it happens on its own over the course of the next few days). Using "Breeze" decorations. I noticed that "Dolphin" (at the moment at least, with kill -9) does not seem to be affected, which is weird. Many gtk and at least some qt applications are affected. Recompiled one of the affected applications (smplayer "Using Qt 5.7.0 / compiled with Qt 5.6.0") but it's still affected now that it has been compiled with Qt 5.7.0. --- ( I normally only use -9 on kwin, when an instance of kwin freezes with 100% cpu and can't be killed or replaced in other ways... nvidia libgl or something on that lvl might be what causes those freezes in the first place, so asking it nicely to stop just doesn't work. )
> Many gtk Please confirm this for anything that's *not* gtk3 because it could be a client reaction to WM losses. (client side decoration and/or removing-this-nonsense plugins on top)
Phew... this is a bit messy, but I think: Konqueror, Qsynth and Smplayer are affected by the bug. Dolphin, Konsole, Qtcreator are NOT affected. Pretty much all gtk applications I tried are affected. claws-mail (gtk+ 2) and Firefox gain "immunity" while it is full height (does not have to be maximized, just vertically maximized or tiled to one half of the screen)... if it's less then full height, it is affected, too. Other apps like xfce terminal seem to always be affected unless they are full screen. And Dragon player expands downwards out of the screen (gets bigger) instead of wandering downwards, but only if it is corner-tiled in the lower half. Otherwise it is not affected.
This is on killing kwin, I assume?! Please dump xprop and xwininfo on dolphin, qtcreator, smplayer and konqueror as well as ldd `which dolphin` ldd `which konqueror` ldd `which smplayer` ldd `which qtcreator` # no idea whether that's the actual binary name ;-)
Created attachment 100203 [details] ldd-xprop-xwininfo
> This is on killing kwin, I assume?! Yes, used killall -9 (the random occurences / crashes were uncooperative and never happened when I had time to pay them any attention).
Thanks for your efforts and sorry for the delay. The only apparent pattern* is that they all seem to be quick tiled (at least it looks like) so this really does seem to be the trigger. As for myself, I'm sorry to say that I won't be available anymore - I removed myself from kwin bugs, so don't wonder why I will no more reply ;-) Good bye, everyone. * crosses Qt4 & Qt5, KDE and plain Qt
This bug report is quite old. Can anyone still reproduce this issue with KDE 5.23?
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!