https://bugs.kde.org/show_bug.cgi?id=357213
--- Comment #7 from Thomas Lübking <thomas.luebk...@gmail.com> --- It'll likely be in QToolBar. I assume the widget flag update (for some reason it changes between managed and unmanaged windows and the sane ones are all managed while the insane one was not) "fails" Ultimately QWidget::hide for the unmanaged floater (it *does* show up in the 0,0 corner - but this seems to only happen with the breeze style?) will fail and you end up with a zombie window (though this is rare here, the typical result is two qwidget representations *in* the window as in my uncomposited screenshot) - the compositor should not see/render an extra window in your screenshot anymore at all (the kate window is one big opaque block from the WM/Compositor POV) There certainly is a bug, but it's not in the compositor. The client has problems to control its windows mapping states (it clearly forgets to close/hide one of the widgets) - the 2nd widget in my shot reacted "live" (ie. reflected input, also on the other widget) and your description sounds as if the zombie toplevel behaves the same?! The compositor *might* trigger this (less/slower syncs, more delay between map request and success, the redirection, something else), but that would boil down to "your system is to slow to correctly handle toolbars" and be no excuse. -- You are receiving this mail because: You are watching all bug changes.
