- 
    Bug 
- 
    Resolution: Done
- 
    P2: Important 
- 
    4.6.3
- 
    None
- 
    None
- 
        723cd931cc15a3ce075c575f1d08e4586177521f
    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.