force posted events before timer timeouts in KDE4 event loop (bnc#467278)

In this particular case, basctl::Shell::onDocumentCreated() and pretty much
everything in basctl/ it seems operate on the current window. The "OnNew"
event that triggers this comes from a timeout generated who knows where
for whatever reason. However, the code "knows" what the current window
is by having basctl::Shell::SetCurWindow() react on events about the current
window changing ... which come from posted events.

So, unless it's defined somewhere that an ordering here must exist, this
is inherently racy. At least generic and Gtk event loops appear to always
deliver the posted event first, so force the same ordering in the KDE
event loop handling.

Change-Id: Ia098f6b45e6b5a5133a12a9172eb09069e6362f9
(cherry picked from commit 8100131214ac2ee46b632703d8ba2babeaf3b5f6)

1 files changed, 10 insertions, 0 deletions

diff --git a/vcl/unx/kde4/KDEXLib.cxx b/vcl/unx/kde4/KDEXLib.cxx
index 86663b5fac45..4f25360ba9e3 100644
--- a/vcl/unx/kde4/KDEXLib.cxx
+++ b/vcl/unx/kde4/KDEXLib.cxx
@@ -349,6 +349,16 @@ void KDEXLib::StopTimer()
 
 void KDEXLib::timeoutActivated()
 {
+    // HACK? Always process posted events before timer timeouts.
+    // There are places that may watch both both (for example, there's a posted
+    // event about change of the current active window and there's a timeout
+    // event informing that a document has finished loading). This is of course
+    // racy, but both generic and gtk event loops manage to deliver posted events
+    // first, so it's at least consistent, and it probably kind of makes at least
+    // some sense (timeouts should be more ok to wait and be triggered somewhen).
+    while( SalKDEDisplay::self()->HasUserEvents() )
+        SalKDEDisplay::self()->DispatchInternalEvent();
+
     X11SalData *pData = (X11SalData*)ImplGetSVData()->mpSalData;
     pData->Timeout();
     // QTimer is not single shot, so will be restarted immediatelly