https://bugs.kde.org/show_bug.cgi?id=406784
Vlad Zagorodniy <vladz...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Latest Commit| |https://commits.kde.org/kwi
| |n/c438ecbb702e970004e7e97e6
| |734f57caef32ea5
Resolution|--- |FIXED
Status|CONFIRMED |RESOLVED
--- Comment #9 from Vlad Zagorodniy <vladz...@gmail.com> ---
Git commit c438ecbb702e970004e7e97e6734f57caef32ea5 by Vlad Zagorodniy.
Committed on 03/05/2019 at 18:25.
Pushed by vladz into branch 'master'.
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.
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/D20916
M +15 -0 client.cpp
M +1 -6 workspace.cpp
https://commits.kde.org/kwin/c438ecbb702e970004e7e97e6734f57caef32ea5
--
You are receiving this mail because:
You are watching all bug changes.
