Bug 351014

Summary: Windows sometimes are translated upwards
Product: [Plasma] kwin Reporter: unsuspicious.fakename+kdebugs
Component: generalAssignee: KWin default assignee <kwin-bugs-null>
Status: RESOLVED WORKSFORME    
Severity: normal CC: paulloock
Priority: NOR    
Version First Reported In: 5.3.2   
Target Milestone: ---   
Platform: Arch Linux   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description unsuspicious.fakename+kdebugs 2015-08-05 20:29:27 UTC
Several times per day, I notice that a random (many different / unrelated applications) window was translated upwards. The height of the spontaneous change in position seems to be identical to the height of the window decoration title bar. If the window was at the top of the screen before the translation, the title bar lands exactly outside of the screen afterwards while the whole rest of the window is still inside of the screen, making it impossible to close or drag back without using alt+drag.

Usually, it's just a few windows (maybe 2 out of 20) and I have not been able to reproduce this problem systematically / reliably. Most of the time, prior to me noticing the problem, I used a different TTY and had to disable + re-enable compositing (alt+shift+F12) after switching back to the KDE session (due to an unrelated graphics corruption bug). This could be random though. 

Reproducible: Sometimes
Comment 1 Thomas Lübking 2015-08-05 20:53:53 UTC
Any of this possibly involved?
- un/maximization
- quick tiling (drag to edges to tile)
- shading (collapse into titlebar)
- multiscreen setup
- qt5 modal dialogs (they'll start to request geometries on un/mapping)

As only some windows are affected:
any pattern on them? (Qt4, Qt5, GTK+, GTK3, Firefox ;-)

In any case, please log the output of
   qdbus org.kde.KWin /KWin supportInformation

---
OT: the graphics corruption (nvidia blob?) might be worked around in 5.4
Comment 2 unsuspicious.fakename+kdebugs 2015-08-05 21:53:30 UTC
- un/maximization 
NOPE
I never do that. As far as I can remember, the only maximized window I have (one of several firefox) was never affected.

- quick tiling (drag to edges to tile) 
MAYBE indirectly?
That I always do with all window, but only once and then I leave them like this for weeks (until I have to reboot). This is also how I notice this bug - I usually have all windows tiled / spread over many desktops and don't move them around. 

- shading (collapse into titlebar) 
NOPE
Never ever did that (except accidentally when trying to adjust volume), doesn't even work at the moment so there's no way this could be involved (maybe I disabled it somewhere if there's a setting for it, I always hated that feature)

- multiscreen setup - qt5 modal dialogs (they'll start to request geometries on un/mapping)
NOT likely
I only have one screen. I guess "qt5 modal dialogs" are the floating / temporary ones? Can't tell for sure if those are affected at all, since I rarely leave them open + in a distinct position where I'd notice if it changed. 

I can tell for sure that the following are affected:
- smplayer Using Qt 5.5.0 (compiled with Qt 5.4.1)
- Konsole Using KDE Frameworks 5.12.0
Because I have many instances of those open (corner-tiled). 

I think I've seen it happen to gtk3 and xul applications too on occasion, but I'll have to leave a few more of those open for some days before I can tell for sure. 

Here's the output of qdbus org.kde.KWin /KWin supportInformation:
https://paste.kde.org/pcz9ff5mk

__
OT: the nvidia blob graphics corruption might be worked around in 5.4? Nice / thx!
Comment 3 Thomas Lübking 2015-08-05 22:32:00 UTC
You may want to create a window rule ("kcmshell5 kwinrules") for smplayer and/or konsole, that says

"Size & Position"/"Ignore requested geometry"/Force/Yes
Maybe also "Obey geometry restrictions"/Force/No

This should forbid the window to move itself around (so we could say whether it's something the client doe, or kwin does, eg. on reconstruction of the titlebar)
Comment 4 unsuspicious.fakename+kdebugs 2015-08-07 09:36:36 UTC
Was waiting for it to happen again with the window rule, but it didn't. Removed the window rule, still no problems so far. This could still be coincidence, so I guess I'll have to wait a few more days without window rule to be sure before I start trying to figure out if I accidentally "fixed" anything while I was trying to get to the bottom of this by reverting changes based on my last backup.

Also, both plasmashell and kwin seem to be suspiciously stable now (I thought it was normal that they take turns silently crashing and "secretly" restarting every once in a while, but for now at least they stopped doing that and just keep on running). Manually killing / restarting either one (even with -9) repeatedly did not trigger the problem before (tested that extensively a few days ago while I was trying to find a way to reliably reproduce the problem), so I thought the two were unrelated. Not totally sure anymore now... maybe they just need to crash more "ungracefully" than with "kill -9" for the problem to occur.

Among the most memorable changes I made during testing (/before the window positioning problem disappeared) were:
- Deleting the old "startup session" and saving a new one. 
- Setting "options nvidia NVreg_RegisterForACPIEvents=1 NVreg_EnableMSI=1"
- Kernel update (4.1.3 -> 4.1.4) and nvidia (352.21 -> 352.30)
- Recompiled kdebase-runtine and kio-extras (only updated build dependency was exiv2 though, so that's rather unlikely)

Since I don't know how to trigger the problem reliably, I'll have to wait until I'm reasonably sure it does/doesn't occur between changes, so this could take a while :/ not sure if there's anything else I could try in the meantime.
Comment 5 unsuspicious.fakename+kdebugs 2015-08-10 10:05:37 UTC
It took an unusually long time, but it happened again (despite all the changes I made / without undoing anything), this time to both of the smplayer windows and nothing else. A window rule for them was in place - "Size & Position"/"Ignore requested geometry"/Force/Yes. I noticed that I accidentally set "Obey geometry restrictions" to yes, too, instead of no, so I guess that means I'll have to change that and wait - again - if it keeps happening?

The problem keeps occurring so unexpectedly, that I can barely guess when I last looked at the windows and what I've done since. Trying anyways: Yesterday evening, they were probably still in the right place. Since then, I've switched to an xfce session running wine on a different tty + different user a couple of time, suspended, resumed... nothing else. I tried forcing the problem to occur by doing exactly those things repeatedly before though - without success. 

The windows were both edge-tiled to one side above each others. The translation height affected both windows, was the same for both windows and included exactly the title + menu bar. (Probably should have mentioned: I've been using the exact same setup / "layout" with compiz standalone for several years and with the old kde4 for almost a year without problems ).
Comment 6 Thomas Lübking 2015-08-10 19:07:35 UTC
*S*mplayer doesn't have geometry restrictions (aspect ratio), but the quick tiling is suspicious.

It *may* then be fixed by https://git.reviewboard.kde.org/r/123882/diff/3#index_header in 5.4 (repeat after me: *may*, *if* this is for some deco/border update)
Comment 7 unsuspicious.fakename+kdebugs 2015-08-11 12:39:39 UTC
Hmm, now that I had a closer look and focused on "corner-tiled" windows, it seems it happens only to those (the ones "snapped" to one quarter of the screen but NOT the ones tiled to half the screen) and I managed to semi-reliably reproduce it (took a while, still) by hibernating + resuming a lot (doesn't always happen and not to all windows, but with lots of corner tiled windows open it is clearly observable). 

It can happen multiple times to the same window (first time, the title bar "snaps" out of the screen, second time the menu bar, then parts of the window begin to disappear).

All applications that I tested (corner - tiled) were affected: smplayer, konsole and pavucontrol (gtkmm3).
Comment 8 unsuspicious.fakename+kdebugs 2015-11-20 11:55:26 UTC
Haven't encountered the bug for some time now with kwin 5.4.3, so while I can't tell for sure, I'm guessing it's fixed.
Comment 9 Thomas Lübking 2015-11-20 16:24:48 UTC
Many thanks for the update.