Bug 49896

Of course, (1) should be: this is _not_ viewer-specific.  -- OB 

Subject: serious eventloop regression

Hi Trolls,

(qt-3.1rc1)

The attached testcase shows that a null single-shot timer started
from a slot connected to a popup menu item will get fired before the
event loop of the menu is left.

Quite some code in KDE relies on this behaviour, allowing to execute
slots 'outside' of the local event loop. Like for example when a
popup menu is executed from within an iconview's mouse event
handler, providing an action that causes the iconview to get deleted
and replace with another view. KDE in that case uses a single-shot
timer to really perform the destructive action when the popup menu
is closed and we're back in the previous/global event loop. The SST
in that case is started from within the slot connected to the
activated() signal of the menu (item) , just like in the testcase.

The testcase works (as in never shows the 'timeout' debug output)
with Qt 2.3.1 as well as with Qt 3.0.5 (sorry, couldn't test any
older 3.0.x versions) .


Simon


Created an attachment (id=328)
test-3.cc

Created an attachment (id=329)
test-1.h

*** Bug 49956 has been marked as a duplicate of this bug. ***

Subject: Re: [Issue N9971]  serious eventloop regression

On Wednesday, 30 Oct 2002 12:45 Simon Hausmann wrote:
> Hi Trolls,

Hello Simon,

> (qt-3.1rc1)
>
> The attached testcase shows that a null single-shot timer started from
> a slot connected to a popup menu item will get fired before the event
> loop of the menu is left.
>
> Quite some code in KDE relies on this behaviour, allowing to execute
> slots 'outside' of the local event loop. Like for example when a popup
> menu is executed from within an iconview's mouse event handler,
> providing an action that causes the iconview to get deleted and
> replace with another view. KDE in that case uses a single-shot timer
> to really perform the destructive action when the popup menu is closed
> and we're back in the previous/global event loop. The SST in that case
> is started from within the slot connected to the activated() signal of
> the menu (item) , just like in the testcase.
>
> The testcase works (as in never shows the 'timeout' debug output) with
> Qt 2.3.1 as well as with Qt 3.0.5 (sorry, couldn't test any older
> 3.0.x versions) .

This is quite true. I hadn't considered this case when I made the
eventloop changes in 3.1.

I have fixed this properly now, and hopefully we won't have problems
like this again.

Here's a patch:

==== //depot/qt/main/src/kernel/qapplication.cpp#723 (text) ====

@@ -2877,14 +2877,6 @@
 		      || receiver == pe->receiver ) // we send to THAT receiver
 		 && ( event_type == 0 // we send all types
 		      || event_type == pe->event->type() ) ) { // we send THAT type
-		// do not process DeferredDelete events if we are in
-		// the middle of a loop level change (which means
-		// exit_loop() has been called, but we have not yet
-		// returned from enter_loop()).
-		if ( eventloop && eventloop->d->exitloop &&
-		     pe->event->type() == QEvent::DeferredDelete )
-		    continue;
-
 		// first, we diddle the event so that we can deliver
 		// it, and that noone will try to touch it later.
 		pe->event->posted = FALSE;

==== //depot/qt/main/src/kernel/qeventloop.cpp#21 (text) ====

@@ -139,8 +139,9 @@
 
     // cleanup
     d->looplevel = 0;
-    d->quitnow = FALSE;
+    d->quitnow  = FALSE;
     d->exitloop = FALSE;
+    d->shortcut = FALSE;
     // don't reset quitcode!
 
     return d->quitcode;
@@ -167,8 +168,9 @@
     if ( d->quitnow ) // preserve existing quitcode
 	return;
     d->quitcode = retcode;
-    d->quitnow = TRUE;
+    d->quitnow  = TRUE;
     d->exitloop = TRUE;
+    d->shortcut = TRUE;
 }
 
 
@@ -182,6 +184,7 @@
     // save the current exitloop state
     bool old_exitloop = d->exitloop;
     d->exitloop = FALSE;
+    d->shortcut = FALSE;
 
     d->looplevel++;
     while ( ! d->exitloop )
@@ -191,10 +194,12 @@
     // restore the exitloop state, but if quitnow is TRUE, we need to keep
     // exitloop set so that all other event loops drop out.
     d->exitloop = old_exitloop || d->quitnow;
+    d->shortcut = d->quitnow;
 
     if ( d->looplevel < 1 ) {
-	d->quitnow = FALSE;
+	d->quitnow  = FALSE;
 	d->exitloop = FALSE;
+	d->shortcut = FALSE;
 	emit qApp->aboutToQuit();
 
 	// send deferred deletes
@@ -212,6 +217,7 @@
 void QEventLoop::exitLoop()
 {
     d->exitloop = TRUE;
+    d->shortcut = TRUE;
 }
 
 /*! \fn void QEventLoop::loopLevel() const

==== //depot/qt/main/src/kernel/qeventloop_p.h#6 (text) ====

@@ -86,12 +86,14 @@
 	quitcode = 0;
 	quitnow = FALSE;
 	exitloop = FALSE;
+	shortcut = FALSE;
     }
 
     int looplevel;
     int quitcode;
-    bool quitnow;
-    bool exitloop;
+    unsigned int quitnow  : 1;
+    unsigned int exitloop : 1;
+    unsigned int shortcut : 1;
 
 #if defined(Q_WS_MAC)
     EventLoopTimerRef select_timer;

==== //depot/qt/main/src/kernel/qeventloop_x11.cpp#17 (text) ====

@@ -146,6 +146,10 @@
 	while ( XPending( QPaintDevice::x11AppDisplay() ) ) {
 	    // also flushes output buffer
 	    while ( XPending( QPaintDevice::x11AppDisplay() ) ) {
+		if ( d->shortcut ) {
+		    return FALSE;
+		}
+
 		XNextEvent( QPaintDevice::x11AppDisplay(), &event );
 
 		if ( flags & ExcludeUserInput ) {
@@ -170,6 +174,10 @@
 	}
     }
 
+    if ( d->shortcut ) {
+	return FALSE;
+    }
+
     QApplication::sendPostedEvents();
 
     // don't block if exitLoop() or exit()/quit() has been called.


> Simon
>
>

--
Bradley T Hughes
Trolltech AS, Waldemar Thranes gt. 98, N-0175 Oslo, Norway

Subject: qt-copy

CVS commit by hausmann: 

- patch from Brad to fix SSTs being fired to early

CCMAIL: 49896-done@bugs.kde.org


  M +1 -0      README.qt-copy   1.176
  M +0 -8      src/kernel/qapplication.cpp   1.58
  M +9 -3      src/kernel/qeventloop.cpp   1.10
  M +4 -2      src/kernel/qeventloop_p.h   1.5
  M +8 -0      src/kernel/qeventloop_x11.cpp   1.7

*** Bug 49600 has been marked as a duplicate of this bug. ***

*** Bug 49600 has been marked as a duplicate of this bug. ***