... when QCoreApplication::processEvents() returns. This is the expected
behavior according to the documentation. Checked also the QUnixEventDispatcherQPA
dispatcher, which did work according to the documentation.
The sequence of events that causes the bad behavior:
1) XCB plugin sends a signals whenever there are new XCB events available
for processing. This signal is connected to QXcbConnection::processXcbEvents,
which will cause XCB events to be added to the QWindowSystemInterface (QWSI) event
queue.
2) When QCoreApplication::processEvents() is called, glib event dispatcher does
one iteration on all attached event sources. First it checks which sources are
ready, and after that starts dispatching events from each source that reported
to be ready.
3) In the case when there are no events in QWSI event queue, the source that handles
QWSI event dispatcing returns 'false'; If at the same iteration the source that
sends posted events (via QCoreApplication::sendPostedEvents()) has returned 'true'
and one of the posted events is to call QXcbConnection::processXcbEvents (due to
signal from step 1) then we get an assert in the following code:
QCoreApplication::processEvents();
Q_ASSERT(QWindowSystemInterface::windowSystemEventsQueued() == 0);
This happens because QXcbConnection::processXcbEvents has posted new events, but
they were not dispatched in this iteration. They would be dispatched in the next
iteration. Events being dispatched on subsequent iteration doesn't really matter
for Qt application, but is inconsistent from API point of view. If we were
populating QWSI queue from non-Gui thread, then it would be possible that
windowSystemEventsQueued() != 0, but that is not the case on XCB (don't know
about other platforms).
The issue could be fixed by always returning true from "check source" and then
simply dispatch 0 events at "dispatch" step if there isn't any in the queue. But
a better solution is to remove the event source all together. It is completely
unnecessary to have this indirection, when we can handle QWSI event dispatch
directly from Qt (like we do, for example, in QUnixEventDispatcherQPA and
QWinRTEventDispatcher). Not having Glib event source for QWSI events would have
also avoided issues that were fixed by fbb485d4f6.
Note, after this re-factoring QWindowSystemInterface::nonUserInputEventsQueued is
now unused, but I left it in as the API by itself is all right.
Task-number: QTBUG-62297
Change-Id: Ia245b835676bd87e63bf02b67036b42a3b1593cc
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
341bfcd1ea