Bug 46142

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I cannot reproduce this in HEAD but it is hard to get the right second for 
the test. I noticed it at daily work.

Also I should note that I use xinerama on the system that makes problems.


thanks
have fun
Felix
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9axK8S0DOrvdnsewRAphbAJ9dXxdelM2XWpWc3eb99B+epnmORgCcCBe3
SCYWr2IUUqjsPj3uX6yHCoY=
=32nP
-----END PGP SIGNATURE-----

Do you have kwin tooltips enabled, and do you see this problem with the kwin 
tooltips?  I see a very similar problem with them, and it's so frequent/bad 
that I had to disable them. 

Subject: Re:  Tooltip doesn't go away when switching to another desktop in some cases

Am Mittwoch, 25. September 2002 17:02 schrieben Sie:
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.
>
> http://bugs.kde.org/show_bug.cgi?id=46142
>
>
>
>
> ------- Additional Comments From staikos@kde.org  2002-09-25 17:02 -------
> Do you have kwin tooltips enabled, and do you see this problem with the
> kwin tooltips?  I see a very similar problem with them, and it's so
> frequent/bad that I had to disable them.
Where can I change this, I have something in Style/misc enabled. I think that 
is the problem. I can't reproduce it with kicker.

btw. After 4 Months with Xinerama I found an option to enable xinerama support 
;)

Is that important ?

thanks
have fun
Felix

Subject: Re:  Tooltip doesn't go away when switching to another desktop in some cases

On September 30, 2002 05:12, Felix Seeger wrote:

> >
> > ------- Additional Comments From staikos@kde.org  2002-09-25 17:02
> > ------- Do you have kwin tooltips enabled, and do you see this problem
> > with the kwin tooltips?  I see a very similar problem with them, and it's
> > so frequent/bad that I had to disable them.
>
> Where can I change this, I have something in Style/misc enabled. I think
> that is the problem. I can't reproduce it with kicker.
>
> btw. After 4 Months with Xinerama I found an option to enable xinerama
> support ;)
>
> Is that important ?

   Hmm yeah it's the same that I see.

  No clue as to what is causing this...

Subject: Re:  Tooltip doesn't go away when switching to another desktop in some cases

Have you read my bugreport, I had an idea but I don't know if that is 
possible.

Am Donnerstag, 3. Oktober 2002 05:56 schrieben Sie:
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.
>
> http://bugs.kde.org/show_bug.cgi?id=46142
>
>
>
>
> ------- Additional Comments From staikos@kde.org  2002-10-03 05:56 -------
> Subject: Re:  Tooltip doesn't go away when switching to another desktop in
> some cases
>
> On September 30, 2002 05:12, Felix Seeger wrote:
> > > ------- Additional Comments From staikos@kde.org  2002-09-25 17:02
> > > ------- Do you have kwin tooltips enabled, and do you see this problem
> > > with the kwin tooltips?  I see a very similar problem with them, and
> > > it's so frequent/bad that I had to disable them.
> >
> > Where can I change this, I have something in Style/misc enabled. I think
> > that is the problem. I can't reproduce it with kicker.
> >
> > btw. After 4 Months with Xinerama I found an option to enable xinerama
> > support ;)
> >
> > Is that important ?
>
>    Hmm yeah it's the same that I see.
>
>   No clue as to what is causing this...

This is not limited to xinerama setups. I can reproduce this on kicker, window decor in multiple decorations (BII and Risc at least), and toolbars of all kde applications (konqueror and kate were tested).  Reproduction is easiest with the window decorations and using fading tooltips. Mouse over the close button and attempt to mouse off as the tooltip is fading in.  This seems to be in library code.  My theory as to whats happening. 1) User moves onto widget with tool tip 2) Tooltip starts to show after some timeout. This should be interrupttable so that if the mouse is moved off, the tooltip will be hidden. 3) User moves off while tooltip is in middle of drawing 4) Tool tip never disappears.  This theory does not make total sense.  Another theory that only makes sense in a multithreaded world: 1) Mouse over widget with tooltip 2) timeout for display expires 3) event processor starts on track to show tooltip 4) mouse off the widget 5) 2nd event processor fires the tooltip hide 6) first event processor fires show tooltip  Different contexts do produce slightly different effects.  In the window decorations, the tooltips never disappear until you re-mouseover the button that produced the tooltip.  In toolbars in applications, the tooltips will disappear after a timeout.  My suspician is that it is somewhere in the QT library. I think it is in qtooltip.cpp somewhere. Search for "case QEvent::MouseMove:" as I think it is in that block of code that points to the error. 

 Great.  Thanks for the analysis.  Lubos said he will try to have a look at 
this now. 

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

I have tracked this problem down to the QT library. A bug report has been sent
to Trolltech.

Please see this mail posted on kde-devel for a description of the problem:
On Sun, 17 Nov 2002, Nicolas Goutte wrote:

> Just send an email (for example the one to which I am replying) to QT Bugs: 
> mailto:qt-bugs@trolltech.com
> 
> Even if a QT has been released recently, you still want Trolltech to know 
> about problems. And if QT Bugs would send you a patch, you could add it to 
> qt-copy.
> 
> Have a nice day/evening/night!
> 
> On Sunday 17 November 2002 21:43, Martin Blix Grydeland wrote:
> > I have found a bug in the released QT V3.1.0 code for producing fade and
> > scroll effects.
> >
> > The code does not reset the WState_ForceHide flag for the real widget (not
> > the transition effect widget) upon start of the animation. If the user
> > code should wish to hide the real widget before the animation has ended,
> > the call the hide() returns premature because this flag is stil set, and
> > the animation widget isn't informed because the hide event is therefor
> > never sent and not picked up in the animation widget's eventlistener. Only
> > after the animation has ended is the real widget updated and show()-ed,
> > and a hide() call at this point is effective.
> >
> > The bug can be seen for most tooltips if you move the mouse pointer away
> > from the widget in the time between start and end of fade in. The tooltip
> > is left on the screen until the mouse pointer reenters the widget to wich
> > it belongs.
> >
> > As far as I can see this constitutes a bug in QT, but probably won't be
> > fixed for a while as they have just had a release. A workaround in KDE
> > could be to clear the WState_ForceHide flag before starting the animation,
> > but there seem to be alot of places to fix.
> >
> > What action should be taken I don't know, but someone on this list who is
> > more familiar with QT-bugreporting might want to take up the thread?
> >
> > Best regards,
> > Martin Blix Grydeland

Created attachment 493 [details]
Patch against qt-copy received originally from TT which fixes the problem

This patch makes QT correctly reset the WState_ForceHide flag for the real
widget. Received from TT as reply to bug report (Issue N11194).

I have tested this and it seems it fixes all instances of dangling tooltips -
both window title buttons and toolbar buttons and regular buttons.

Maybe this should be included in qt-copy?

qt bug. fixed.