Details
-
Bug
-
Resolution: Done
-
P2: Important
-
4.6.3
-
None
-
None
-
723cd931cc15a3ce075c575f1d08e4586177521f
Description
When GSource prepare or check functions return TRUE, Glib does not
necessary call the dispatch function immediatelly (probably depends
on the ordering of processing events). This means that
timerSourceDispatch() may get called from different call of
QEventDispatcherGlib::processEvents() than its accompanying
timerSourcePrepareHelper() or timerSourceCheckHelper().
This is a problem if a timer becomes pending during a normal
processEvents() call but will only be executed during a call
to processEvents() with QEventLoop::X11ExcludeTimers. The attached
patch fixes this problem by rescheduling the timer for another pass.
As for a testcase, this happens when making LibreOffice's KDE
integration use Qt event loop, requires setting the useEventLoop
property on the QClipboard object, so I'm afraid I don't have anything
simple. But fact that Glib can keep an event pending for a little
moment is rather obvious from its sources or can be triggered
from any Qt application, and I hope the rest is an obvious consequence.