Author: Yuri Nesterenko Date: 03/Nov/11 08:56 AM
Author: Artem Ananiev Date: 07/Nov/11 04:25 PM
Raising priority to critical as it likely affects all the automatic modality tests.
Author: Leonid Romanov Date: 19/Dec/11 05:40 PM
There is an event number associated with every NSEvent. For real events, the numbering starts at some value close to zero and gets incremented on each button press. Apparently, the window server uses event numbers to determine windows z-order. One might expect that Apple API for synthesizing mouse events takes care of all that numbering stuff and assigns correct event numbers automatically, but it is not the case: you have to explicitly set the event number, otherwise it will be zero.
And this is why the test fail: because of the zero event numbers. They somehow confuse the window server.
The fix seems to be clear: set correct event numbers for the generated events. However, Apple docs are completely silent about the importance of event numbers and don't provide any guidance on how they should be generated. Also, there is no API for obtaining current event number. It seems, though, that event numbers for the generated events must be higher than the event number for the last real mouse event. So, the solution suggested by Internet is to start numbering at some arbitrary number that is high enough, like 40000 or something. Although it doesn't guarantee for sure that generated events will have event numbers higher than real events, it should work in the most cases.