Summary: | kwin crash when restarting IntelliJ application | ||
---|---|---|---|
Product: | [Plasma] kwin | Reporter: | Marcus Better <marcus> |
Component: | general | Assignee: | KWin default assignee <kwin-bugs-null> |
Status: | RESOLVED WORKSFORME | ||
Severity: | crash | Keywords: | drkonqi |
Priority: | NOR | ||
Version: | 5.13.5 | ||
Target Milestone: | --- | ||
Platform: | Debian testing | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Marcus Better
2018-11-08 17:53:48 UTC
It looks like we're re-inserting deleted Client's. For example, if we have the following unconstrained stacking order unconstrained_stacking_order: { 0x5632110c9870, 0x5632110aac50, 0x5632110ddf50, 0x5632111b3100 } and releaseWindow is called on Client 0x5632111b3100 (the last one), then Workspace::addDeleted will replace that client with a corresponding Deleted instance 0x563211181860 unconstrained_stacking_order (after addDeleted was called): { 0x5632110c9870, 0x5632110aac50, 0x5632110ddf50, 0x563211181860 } but when Workspace::constrainedStackingOrder is called, we have the following unconstrained stacking order unconstrained_stacking_order: { 0x5632110c9870, 0x5632110aac50, 0x5632110ddf50, 0x563211181860, 0x5632111b3100 } It looks like in my case, raiseClient is called, which in its turn, adds the deleted Client back to unconstrained stacking order. In case of bug 392412, it looks like sendClientToDesktop indirectly triggers raiseClient. --- @Marcus Do you use some fancy scripts to open/maximize windows on new virtual desktops? No, I have a plain Debian install. No fancy scripts that I know of. Git commit 8af6d4f5dc74385a9d52820562162dc190f452ff by Vlad Zagorodniy. Committed on 26/11/2018 at 08:50. Pushed by vladz into branch 'master'. [x11] Emit clientRemoved after client was removed Summary: Currently, there is a guarantee that a client, which is about to be removed, is no longer in the stacking order(both in constrained and unconstrained) when Workspace::removeClient is called. However, because the client gets removed from m_allClients after clientRemoved is emitted, it can be re-inserted back into the stacking order. In general, the pattern is to do some work and then notify others about what you've done by emitting a signal. In the case of Workspace::removeClient, we emit clientRemoved way before the client actually gets removed. Related: bug 392412 Test Plan: * Enable the following script: ```lang=js workspace.clientAdded.connect(function (client) { if (client.skipTaskbar || client.modal || client.transient) { return; } workspace.desktops = workspace.desktops + 1; workspace.currentDesktop = workspace.desktops; client.desktop = workspace.currentDesktop; }); workspace.clientRemoved.connect(function (client) { if (client.skipTaskbar || client.modal || client.transient) { return; } workspace.desktops = workspace.desktops - 1; }); ``` * Open an app, close the app. Reviewers: #kwin, graesslin Reviewed By: #kwin, graesslin Subscribers: graesslin, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D17069 M +2 -2 workspace.cpp https://commits.kde.org/kwin/8af6d4f5dc74385a9d52820562162dc190f452ff @Marcus Does this happen only when restarting IntelliJ IDEA? I cannot reproduce it consistently, so not sure in which scenarios it happens. Maybe it's fixed in 5.15.0 (I'm still not sure whether we covered all cases, it's quite hard to reproduce this bug). If the crash still happens, please reopen this bug report. Thanks. |