D20916: Switch to the next tabbox item before currently highlighted client is removed from stacking order

zzag created this revision.
zzag added a reviewer: KWin.
Herald added a project: KWin.
Herald added a subscriber: kwin.
zzag requested review of this revision.

REVISION 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).

REPOSITORY
  R108 KWin

BRANCH
  tabbox-switch-to-next-before-destroying-highlighted-client

REVISION DETAIL
  https://phabricator.kde.org/D20916

AFFECTED FILES
  client.cpp
  workspace.cpp

To: zzag, #kwin
Cc: kwin, jraleigh, GB_2, mkulinski, ragreen, jackyalcine, Pitel, iodelay, bwowk, ZrenBot, ngraham, alexeymin, lesliezhai, ali-mohamed, hardening, jensreuterberg, abetts, sebas, apol, mart