Don't crash when highlighted tabbox client is closed
Summary: The compositor tries to switch to the next tabbox client when currently highlighted client is closed. Though there is a small issue with that. Because the switch happens too late, a dangling pointer can be inserted into the unconstrained stacking order, which can lead to a crash later on. There are two cases: - compositing is on; - compositing is off. Compositing is on: TabBox will try to un-elevate currently highlighted client, though by that time the client no longer owns EffectWindow, so this is basically a no-op (that's why we haven't experienced this bug before). Compositing is off: TabBox will try to restack currently hightlighted client under the next tabbox client. Given that the restack method doesn't do any sanity checks(see Client::manage why), a client that is about to be destroyed will be re-inserted back into the unconstrained stacking order. This change ensures that the switch happens before currently highlighted client is removed from the stacking order. BUG: 406784 Test Plan: - Turn off compositing; - Follow steps to reproduce in the bug report (see comment 2). Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D20916master
parent
0fb09cf413
commit
c438ecbb70
Loading…
Reference in New Issue