When a window is withdrawn kwin (5.8.5) removes the WM_STATE property and clears _NET_WM_STATE. The netwm spec says this about _NET_WM_STATE: "The Window Manager should remove the property whenever a window is withdrawn, but it should leave the property in place when it is shutting down, e.g. in response to losing ownership of the WM_Sn manager selection." Due to this, applications/toolkits have to be careful about dealing _NET_WM_STATE property updates for withdrawn windows.
Btw Qt 5.6.1/5.7.0 works around this issue (QTBUG-55942).
I tried to track down whether there are any changes in KWin related to that. The relevant code is in KWin::Client::releaseWindow: info->setState(0, info->state()); // Reset all state flags This code has not seen any changes in year. I tracked it down through two coding style changes and ended in a change "branches/work/kwin_composite becomes new trunk kwin" in 2007 where I'm no longer able to follow with git blame. But it's clear the code hasn't changed for a decade at least. So I looked at the implementation of NetWinInfo::setState. There I went back to the KDE 4.0 branch where this method only clears but does not delete the property. The oldest code I found is from 2007 as well and also didn't delete the property. The relevant code section has an interesting copyright header: Copyright (c) 2000 Troll Tech AS Qt implemented it that way in 2000. They didn't have a problem with their implementation for almost 2 decades. If KWin was not 100 % spec compliant in this point for > 15 years without any application or toolkit having a problem with it I must say that KWin's behavior is kind of a de-facto standard. The EWMH standard is unfortunately hardly implemented correctly by any window manager - in fact it's impossible to implement it correctly as it's contradicting. Overall I don't think this is an issue which we should fix. The risk of breaking another application is too high given that KWin behaved like that for such a long time.
(In reply to Martin Flöser from comment #2) > I tried to track down whether there are any changes in KWin related to that. > The relevant code is in KWin::Client::releaseWindow: > > info->setState(0, info->state()); // Reset all state flags > > This code has not seen any changes in year. I tracked it down through two > coding style changes and ended in a change "branches/work/kwin_composite > becomes new trunk kwin" in 2007 where I'm no longer able to follow with git > blame. But it's clear the code hasn't changed for a decade at least. > > So I looked at the implementation of NetWinInfo::setState. There I went back > to the KDE 4.0 branch where this method only clears but does not delete the > property. The oldest code I found is from 2007 as well and also didn't > delete the property. The relevant code section has an interesting copyright > header: Copyright (c) 2000 Troll Tech AS > > Qt implemented it that way in 2000. They didn't have a problem with their > implementation for almost 2 decades. If KWin was not 100 % spec compliant in > this point for > 15 years without any application or toolkit having a > problem with it I must say that KWin's behavior is kind of a de-facto > standard. The EWMH standard is unfortunately hardly implemented correctly by > any window manager - in fact it's impossible to implement it correctly as > it's contradicting. > > Overall I don't think this is an issue which we should fix. The risk of > breaking another application is too high given that KWin behaved like that > for such a long time. A toolkit did have a problem with this - Qt. Hence the workaround I referred to in comment 1. > Overall I don't think this is an issue which we should fix. The risk of breaking another application is too high given that KWin behaved like that for such a long time. I don't think the risk is terribly big as other window managers follow the spec closer here. But it is a minor issue and Qt already has a workaround, so a wontfix is not a terrible loss for the world :-)
> I don't think the risk is terribly big as other window managers follow the spec closer here. The question is: why was it wrong in KWin? Given the age of the code it's quite likely that there were/are applications/toolkits not handling it correctly, so KWin had to do a workaround.