When debugging modifier_only_shortcut_test in _waylandonly mode I saw
that it was failing, among other things, because some aspects were not
initialised.
This changes every test we have to run the new
Test::initWaylandWorkspace() that calls waylandServer()->initWorkspace()
but also makes sure that WaylandServer::initialized is emitted before we
proceed.
A window id generated by WaylandServer may reference an X11 window
with the same id, which can result in undefined behavior.
The main reason why we needed windowId() was because of the task
switcher. However, since tabbox uses internal ids now, the window id
property can be dropped.
If Xwayland has crashed, the Workspace will block stacking order updates
and start destroying all X11 clients.
Once stacking order updates are unblocked, the Workspace will mark the X
stacking order as dirty and create a new Xcb::Tree object.
We don't want to create that Xcb::Tree object because accessing it
after the XCB connection has been shut down will lead to a crash.
BUG: 427688
FIXED-IN: 5.20.1
If the Xwayland process has crashed due to some bug, the user should
still be able to start applications in Xwayland mode. There is no reason
to restart the whole session just to be able to launch some application
that doesn't have native support for Wayland.
