9c611ddaea
On X11, the stack order of a window can be changed in multiple ways:
- Opposite
- TopIf
- BottomIf
- Above
- Below
You would pass either of those modes plus maybe the above window id. For
this crash, the relevant mode is Above.
Since the Workspace only has one restack function that places the given
window right under the reference window, the Above stack mode
implementation performs a quirk: it walks through the stack in order to
find a window right above the reference window and pass it to the
restack() function.
However, it could be that the window that wants to be restacked is already
above the reference window, so that same window would be passed as the
"under" window to the restack() function.
It's nothing but a miracle that we have not received major complaints
about this issue until now.
The restack() function doesn't like `window` and `under` to be the same
because of code like
unconstrained_stacking_order.removeAll(window);
unconstrained_stacking_order.insert(unconstrained_stacking_order.indexOf(under), window);
The removeAll() function would effectively remove both `window` and `under`
from the unconstrained stack, which breaks the next line because the
indexOf() would return -1, i.e.
unconstrained_stacking_order.insert(-1, window);
This is the reason why the unconstrained_stacking_order contains strange
values such as `0xe`.
In order to fix the crash, this change adds some code to short-circuit
the restack() function if the passed in window and the reference window
are the same. It would be great to clean up X11Window::restackWindow()
and also add ergonomic restack functions in the Workspace, but this can
be done later. The major blocker is lack of proper test coverage of
X11 bits at the moment.
Last but not least, I would like to express my profound gratitude to
Peter Strick for filing the crash report AND providing a VM image that
helped massively with reproducing the crash and finally fixing it.
BUG: 491618
|
||
|---|---|---|
| autotests | ||
| cmake/modules | ||
| data | ||
| doc | ||
| examples | ||
| kconf_update | ||
| LICENSES | ||
| po | ||
| src | ||
| tests | ||
| .clang-format | ||
| .gitignore | ||
| .gitlab-ci.yml | ||
| .kde-ci.yml | ||
| CMakeLists.txt | ||
| CONTRIBUTING.md | ||
| KWinDBusInterfaceConfig.cmake.in | ||
| logo.png | ||
| Mainpage.dox | ||
| plasma-kwin_wayland.service.in | ||
| plasma-kwin_x11.service.in | ||
| README.md | ||
KWin
KWin is an easy to use, but flexible, composited Window Manager for Xorg windowing systems (Wayland, X11) on Linux. Its primary usage is in conjunction with a Desktop Shell (e.g. KDE Plasma Desktop). KWin is designed to go out of the way; users should not notice that they use a window manager at all. Nevertheless KWin provides a steep learning curve for advanced features, which are available, if they do not conflict with the primary mission. KWin does not have a dedicated targeted user group, but follows the targeted user group of the Desktop Shell using KWin as it's window manager.
KWin is not...
- a standalone window manager (c.f. openbox, i3) and does not provide any functionality belonging to a Desktop Shell.
- a replacement for window managers designed for use with a specific Desktop Shell (e.g. GNOME Shell)
- a minimalistic window manager
- designed for use without compositing or for X11 network transparency, though both are possible.
Contributing to KWin
Please refer to the contributing document for everything you need to know to get started contributing to KWin.
Contacting KWin development team
- mailing list: kwin@kde.org
- IRC: #kde-kwin on irc.libera.chat
Support
Application Developer
If you are an application developer having questions regarding windowing systems (either X11 or Wayland) please do not hesitate to contact us. Preferable through our mailing list. Ideally subscribe to the mailing list, so that your mail doesn't get stuck in the moderation queue.
End user
Please contact the support channels of your Linux distribution for user support. The KWin development team does not provide end user support.
Reporting bugs
Please use KDE's bugtracker and report for product KWin.
Guidelines for new features
A new Feature can only be added to KWin if:
- it does not violate the primary missions as stated at the start of this document
- it does not introduce instabilities
- it is maintained, that is bugs are fixed in a timely manner (second next minor release) if it is not a corner case.
- it works together with all existing features
- it supports both single and multi screen (xrandr)
- it adds a significant advantage
- it is feature complete, that is supports at least all useful features from competitive implementations
- it is not a special case for a small user group
- it does not increase code complexity significantly
- it does not affect KWin's license (GPLv2+)
All new added features are under probation, that is if any of the non-functional requirements as listed above do not hold true in the next two feature releases, the added feature will be removed again.
The same non functional requirements hold true for any kind of plugins (effects, scripts, etc.). It is suggested to use scripted plugins and distribute them separately.