Since Rawhide compose Fedora-Rawhide-20220119.n.0, openQA tests of install from the KDE live image have been failing consistently. What seems to happen is, a fairly short time after the installer starts up, mouse clicks from openQA on elements of anaconda just seem to...stop working.

anaconda is actually still working - lruzicka found that if we use openQA's 'development mode', which lets you hijack its VNC connection manually, he could click on things OK. And openQA can still click on things outside of the anaconda window. But any attempt by openQA to click on anything inside the anaconda window just doesn't work, it doesn't do anything.

This is not affecting the Workstation image or the traditional installer images. It's only affecting KDE.

The changes in Fedora-Rawhide-20220119.n.0 included bumps of most of KDE/Plasma from 5.23.5 to 5.23.90, so that seems like the obvious suspect here. anaconda and GTK+ were not changed. kwin seems like the *most* likely related component, so I went with that to start with.

Here's some more detail on exactly how openQA (well, technically os-autoinst, the test runner component) "clicks on things", all via qemu's built-in VNC server:

* Match the relevant area and determine its centre point
* Set the cursor to that precise position; it does not "move" the cursor the way a human would, it just zaps it there with a single VNC event (see https://github.com/os-autoinst/os-autoinst/blob/master/consoles/VNC.pm#L745-L760)
* Send a 'mouse button down' event
* Wait 0.15 seconds
* Send a 'mouse button up' event
* Wait 1 second
* Set the cursor to 1023,767: this is called a "mouse hide" event, the purpose is to position the cursor somewhere we hope it won't happen to interfere with a subsequent match attempt (i.e. the bottom right corner of the screen)

So each time we 'click on something', that's what happens. The bug seems to start happening after about the second or third time we click on something in anaconda.

Possibly also relevant: os-autoinst by default runs qemu with an emulated tablet for input, not an emulated mouse (as virt-manager also does, these days). I believe this is supposed to make input smoother or more efficient somehow, I forget the details. There is a way you can configure it not to do this, I'll test with that set to see if it makes any difference.