Bug 275469

I can confirm that. Also sometimes when i open app that app doesnt show up in taskbar, if i open one more app then both show up. And thats kind of annoying it happens quite frequently. This didnt happen with kde 4.6.

I can confirm the same bug for me after update KDE from 4.6.5 to 4.7.0 using Kubuntu 11.04 amd64 and QT 4.7.2

Yes. I have the same problem in Kubuntu 11.04  ( upgrated to 4.7.0 ). Sometimes I can see applications on taskbar after closing them and applications without a title.

I changed to opensuse 11.4 x86_64 and after upgrading to KDE 4.7 got the same problem again. I'm using Intel hd4500 video GPU on my Dell 1537 Studio. Anyone with Intel have same problem?

I have exactly the same bug, when upgraded from kde 4.6.5 to 4.7.0.
This bug also appears when using Smooth Tasks widget instead of standard taskbar.
OS: opensuse 11.4 x86_64.
Video adapter: Intel Core i5-650 integrated.

*** This bug has been confirmed by popular vote. ***

I can confirm this comment. I also tried with Smooth taskbar and got same issue. I think that it's not related with plasma widget, but with plasma and Xorg interaction instead. Please let me know which logs may I provide you help detect the issue.

(In reply to comment #5)
> I have exactly the same bug, when upgraded from kde 4.6.5 to 4.7.0.
> This bug also appears when using Smooth Tasks widget instead of standard
> taskbar.
> OS: opensuse 11.4 x86_64.
> Video adapter: Intel Core i5-650 integrated.

Created attachment 62632 [details]
example of stuck tasks on bar

example of stuck tasks on bar

Bug https://bugs.kde.org/show_bug.cgi?id=279769 is probably a duplicate but I haven't marked it as such yet as it contains some information that has not been included here.

To summarise bug #279769, if an application is closed using the "x" button then the taskbar icon is not removed. If an application is closed using a keyboard shorcut (e.g. Alt-F4) or the application's file menu then the icon is removed correctly. Does this explain the "sometimes" that people are experiencing? If it does then bug #279769 can be marked as a duplicate, if not then there may be two similar but related bugs and each one needs to be looked into further.

(In reply to comment #9)
> Bug https://bugs.kde.org/show_bug.cgi?id=279769 is probably a duplicate but I
> haven't marked it as such yet as it contains some information that has not been
> included here.
> 
> To summarise bug #279769, if an application is closed using the "x" button then
> the taskbar icon is not removed. If an application is closed using a keyboard
> shorcut (e.g. Alt-F4) or the application's file menu then the icon is removed
> correctly. Does this explain the "sometimes" that people are experiencing? If
> it does then bug #279769 can be marked as a duplicate, if not then there may be
> two similar but related bugs and each one needs to be looked into further.

Dear Paul,
I've tried with ALT+F4 and seems like I can reproduce this problem less time that using "x" button, because after trying almost 30 times to close the same application with this button combination I got frozen icon on taskbar again. I also noted that sometimes when opening any application, it's icon on taskbar may not appear until you open any next application and then will see both icons on bar. Please see my next attachments with examples. Maybe this bug can be kind of different for different users, but I'm sure that the bug you've reported is related with this one. 

I read in some forum that KDE had same issue in it's release 4.2 but they've fixed it after some updates. Unfortunately, actual bug has not been fixed since many KDE updates installed and it's also reproducible on fresh installed OS (openSUSE 11.4 or Kubuntu 11.04) and updated with KDE 4.7.
I still insist that this bug is not related with widget-taskbar because testing other widget such as "smooth tasks" the bug exists.



Cheers.

Created attachment 62824 [details]
No app icon on taskbar after opening it

The icon you see for ksnapshot.

Created attachment 62825 [details]
Frozen taksbar icon after closing with ALT+F4

It's less reproducible when using this key combination instead of click on "x", but reproducible.

(In reply to comment #12)
> Created an attachment (id=62825) [details]
> Frozen taksbar icon after closing with ALT+F4
> 
> It's less reproducible when using this key combination instead of click on "x",
> but reproducible.

I think this is why I created a separate bug report!

On my Kubuntu 11.10 installation I only see the icon on the redundant taskbar icon when I use the 'x' button. It has been this way ever since I noticed this bug.

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

Just found a related thread from Ubuntu forum:
http://ubuntuforums.org/showthread.php?t=974778

can confirm.
OS : arch
KDE SC: 4.7.0
using ati 4770 with xf86-video-ati-6.14.2 as driver

Confirmed with current trunk.

With the added observation that sometimes the stuck taskbar item belongs to a different virtual desktop, even though I have the taskbar set to "Only show tasks from the current desktop".  But it does *not* appear on the desktop that it says it is on!

i have the same problems as well. in addition to programs suddenly flashing in the taskbar, as if they are requiring my attention, when in fact, they're not. and this flashing is quite annoying, as it wont go away.
but after some messing around, i found out that whenever i have flashing programs in the task manager widget, or as others have said, stuck programs, icons of closed programs, etc... i can simply get rid of all the problems by switching to another virtual desktop, then switch back to my active desktop, all windows behave normally after that... well, until they start misbehaving again in few minutes at least :P

I'm also seeing this bug, but I'm also seeing some tasks overlap other tasks.

Overlapping tasks are tracked in bug 22447.

Sorry for the mistake, I meant bug 224447.

Dear All,

I'm wondering if the bug I've reported: https://bugs.kde.org/show_bug.cgi?id=280957 is related to this bug. I'm also experiencing not responsive panel, taskbar etc,...

* My system info:
Application: plasma-desktop (0.4)
KDE Platform Version: 4.7.00 (4.7.0)
Qt Version: 4.7.2
Operating System: Linux 2.6.38-11-generic i686
Distribution: Ubuntu 11.04

Unfortunately not fixed in 4.7.1. 

An answer from a developer (working on it, could not reproduce, no time for it) would be nice. 

Kind regards

yeah, not fixed in 4.7.1. For some reason i start to think that its kwin foult because it seems like it doesnt give correct signal that window is closed.

I just tried with smooth tasks, and well same problem exists with it too. So thats not taskbar plasmoid problem. Theres something in the plasma core or kwin.

Under kde-4.7 (xorg-server-1.10.X) and kde-4.7.1 (xorg-server-1.11.0), every time any gui app is launched (eg, konsole, okular, firefox, thunderbird, any java gui app, etc), I see in ~/.xsession-errors, many BadWindow X errors:

X Error: BadWindow (invalid Window parameter) 3
  Major opcode: 20 (X_GetProperty)

Then, when I close the app, I see the following pair in ~/.xsession-errors:

Object::disconnect: No such signal TaskManager::TaskItem::destroyed(QObect*)
Object::disconnect: No such signal TaskManager::TaskItem::destroyed(QObect*)

I think the BadWindow errors may be an issue with kde and xorg-server-1.10 and above.

The issue of task items not being cleared after the app is closed started with kde-4.7.0, and remains in kde-4.7.1. It does not allows occur, but rather, 60 - 80 % of the time, and seems to rarely occur if you simply launch an app and then immediately close it. Also, I haven't seen it with kde apps, only with gtk-based apps like firefox, and java gui apps. Finally, it may not be associated with the above .xsession-error messages as these messages ALWAYS occur, even when this issue does not.

hope this helps,
John

Any update from devs about this bug? 

It is very very very annoying bug. Personaly it annoys me so much that I still use kde 4.6.5. I hope fix will be released in 4.7.2

I can confirm as well.

A work-around is to:
killall plasma-desktop; sleep 2; plasma-desktop

Another work around is to open and close kmenu. That makes the item disappear.

I can also confirm this (with Kubuntu 11.04 with KDE SC 4.7.0). Opening and closing KMenu - as reported above - seems to work.

Come on, soon 4.7.2 will be tagged and no answer from developers?

@Simonas : I read somewhere on develpoers blog that the bug has bug has been solved in KDE 4.8. So, v may just have to have a little patience until next major release.

(In reply to comment #32)
> @Simonas : I read somewhere on develpoers blog that the bug has bug has been
> solved in KDE 4.8. So, v may just have to have a little patience until next
> major release.


This is quite stupid imo.
1. the fix really fixes all scenarios?
2. is the fix relative small and safe to be backported to 4.7.x? If yes why not?

Honestly this is a bug that should be quite relevant as is confusing users, instead is considered as minor.
Since 4.8 beta is tagged on 17th of Nov 2011 that sounds a bit too late for us to test in case of backport as KDE 4.7.4 is planned to be tagged on 1st of December.

So would be nicer if devs really check what diff fixed the issue and if safe and small consider themself for backporting.

I've tried finding the commit that fixed it in 4.8, but I can't seem to find it. :(

I too am trying to find the site where I had read it. I am sure it was related to this. But am not able find that site. 

Sorry, I coudn't get the link I'll try if I find link I'll post it.

(In reply to comment #26)
> Under kde-4.7 (xorg-server-1.10.X) and kde-4.7.1 (xorg-server-1.11.0), every
> time any gui app is launched (eg, konsole, okular, firefox, thunderbird, any
> java gui app, etc), I see in ~/.xsession-errors, many BadWindow X errors:
> 
> X Error: BadWindow (invalid Window parameter) 3
>   Major opcode: 20 (X_GetProperty)
> 
> Then, when I close the app, I see the following pair in ~/.xsession-errors:
> 
> Object::disconnect: No such signal TaskManager::TaskItem::destroyed(QObect*)
> Object::disconnect: No such signal TaskManager::TaskItem::destroyed(QObect*)
> 
> I think the BadWindow errors may be an issue with kde and xorg-server-1.10 and
> above.
> 
> The issue of task items not being cleared after the app is closed started with
> kde-4.7.0, and remains in kde-4.7.1. It does not allows occur, but rather, 60 -
> 80 % of the time, and seems to rarely occur if you simply launch an app and
> then immediately close it. Also, I haven't seen it with kde apps, only with
> gtk-based apps like firefox, and java gui apps. Finally, it may not be
> associated with the above .xsession-error messages as these messages ALWAYS
> occur, even when this issue does not.
> 
> hope this helps,
> John

I just got the same behaviour using blogilo , so it's not limited to non-KDE apps

The warnings:

Object::disconnect: No such signal TaskManager::TaskItem::destroyed(QObect*)

are due to a bug/typo in libs/taskmanager/launcheritem.cpp; an easy fix is

--- kde-workspace-4.7.1.old/libs/taskmanager/launcheritem.cpp   2011-09-01 16:47:10.000000000 -0400                                         
+++ kde-workspace-4.7.1.new/libs/taskmanager/launcheritem.cpp   2011-09-22 01:27:11.655716912 -0400
@@ -110,7 +110,7 @@ void LauncherItem::associateItemIfMatche
 
 void LauncherItem::removeItemIfAssociated(AbstractGroupableItem *item)
 {
-    disconnect(item, SIGNAL(destroyed(QObect*)), this, SLOT(associateDestroyed(QObject*)));
+    disconnect(item, SIGNAL(destroyed(QObject*)), this, SLOT(associateDestroyed(QObject*)));
 
     // now let's just pretend it was destroyed
     d->associateDestroyed(item);

Not sure why Qt/gcc didn't catch this.. but, alas, this is unrelated to the issue at hand.

Still happening with current trunk (kdelibs branch master) as of today.
Have found this reliable method to create a "stuck" closed window:

Taskbar settings -
Only show windows from the current desktop
Do Not Group
Do Not Sort

Virtual desktops - 4

Open a window on virtual desktop A (e.g. a Konsole).
Set its window title to "foo" or something distinctive.

Set the window to appear on all desktops, via the window-operations menu or windeco's "pin" button.

Switch to virtual desktop B, the window also appears there as would be expected.

Without changing the virtual desktop or any other settings, close the window.  It will disappear from the taskbar on virtual desktop B as expected.

Switch back to virtual desktop A, the window will still be "stuck" in the taskbar.

> Have found this reliable method to create a "stuck" closed window:

I can confirm that this reproduces the bug for me.

I recently upgraded to Oneiric Ocelot (Kubuntu 11.10 beta) which has KDE 4.7.1 
and I no longer see this problem.

@ Kishore: (In reply to comment #40)
> I recently upgraded to Oneiric Ocelot (Kubuntu 11.10 beta) which has KDE 4.7.1 
> and I no longer see this problem.

Quite strange. I use arch linux which uses latest packages of kde and still I see that bug.
Actually it's a bug seen from 4.7 series

After some updates in Kubuntu 11.10 (I think updates are patches from 4.7.2), the bug seems to happen more rare, but still happens.

@Nikola - But can you still reproduce using the methods in commet #38?

@Morten - Yes, I can still reproduce it. It creates empty space on taskbar on dektop 1. And if I try your method few times, more and more empty space on taskbar is made.

Snapshots:
http://www.dodaj.rs/f/3o/wr/4bHWzWRU/snapshot4.jpg
http://www.dodaj.rs/f/25/11c/1KeC2oja/snapshot5.jpg
http://www.dodaj.rs/f/22/CA/4e4UUfLo/snapshot7.jpg

Problem remains with kde-4.7.2.

As a work-around, I just click on the clock to open the calendar, and then immediately click again to close it. This always clears out the dead taskbar entries.

Same here on openSUSE 11.4/x86_64 with KDE 4.7.2. My workaround is to start a new application and then close it.

Just as I suspected... built and installed an updated video driver, presumably now in sync with the latest xorg-server, and the problem has disappeared ...

Developers found a way to workaround the taskbar empty space bug:
http://mail.kde.org/pipermail/plasma-devel/2011-October/017296.html
Can anyone try to build from trunk and see perhaps this commit fixes this taskbar bug too?

Regarding Comment #47, well, for 3 days the problem didn't occur, but today it did. So it looks like a kde 'race issue.' I assume the new driver I installed simply altered relevant timing relationships so that the issue occurs much less frequently.

Created attachment 64503 [details]
fix ghost taskbar entries after closings apps 

Looking at the code in kde-workspace-4.7.2/libs/taskmanager/taskitem.cpp,there appears to be a 'race condition' present involving the destructor TaskItem::~TaskItem() and the SLOT TaskItem::taskDestroyed(), due to TaskItem::setTaskPointer(TaskPtr task) connecting the SIGNAL 'destroyed()' to 'deleteLater()', thus potentially short-circuiting the cleanup in TaskItem::taskDestroyed(). I believe, 'destroyed()' should be connected to 'taskDestroyed()' instead.

The 'connect' statements in the creators appear ok, its only the one in TaskItem::setTaskPointer().

Also, in the destructor TaskItem::~TaskItem(), the 'emit destroyed(this)' statement is suspicious as the SIGNAL 'destroyed()' is received by TaskItem::taskDestroyed() which assumes the pointer 'd' to still be good (since TaskItem::~TaskItem() deletes 'd' immediately after emitting destroyed(), there
is no guarentee that 'd' is still valid when TaskItem::taskDestroyed() receives the signal).

Hopefully, the attached patch fixes this issue (so far for me, it looks good), so if anyone else out there could rebuild kde-workspace-4.7.2 and test, it be great..
thanks,
John

(In reply to comment #48)
> Developers found a way to workaround the taskbar empty space bug:
> http://mail.kde.org/pipermail/plasma-devel/2011-October/017296.html
> Can anyone try to build from trunk and see perhaps this commit fixes this
> taskbar bug too?

I wouldn't bother with the 'workaround'/patch there as it add rather arbitrarily adds QTimers where they shouldn't be needed. Doing this might 'appear' to fix the issue simply by changing code-path timing relationships, but doesn't address the underlying cause (my driver-update did just this, I believe).

Which QTimers are you referring to? The KDE patch does not use QTimers - but they are mentioned in the email thread (by me).

In my IconTasks fork I connect the deleteLater's to QTimers, as otherwise I do not see the destructors being called. (And I also observed this with the KDE taskbar)

Are you saying with your patch that the destructors get called? I tested by adding a qDebug call (printing out the value of the item pointer) before the deleteLater call, and in the items destructor. Without using the QTimers, the destructor was not being called. Admittedly the QTimer addition is just  a hack, and the real reason as to why deleteLater items are not being destroyed need to be found.

Please disregard the comment #50 patch; I'll submit an updated one shortly.

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

Created attachment 64532 [details]
ghost taskbar entries patch

This is a bit more complicated, than I thought.  Qt doc states that a deferred
deletion (via a deleteLater() call) will not be performed if control is not in
the event loop from which the deleteLater() call was made.  So, if an app (eg,
firefox) has its own event loop, and if the deleteLater() call is made while
this event loop is in control, then if the deferred deletion is attempted later)
from another event loop (kde/plasma's or whatever), the deletion will not occur
and TaskItem::~TaskItem will not be called.

Now, the default Qt::ConnectionType is Qt::AutoConnection, which behaves like
Qt::DirectConnection if connection sender and receiver are in the same thread,
and like Qt::QueuedConnection, if not.  In taskitem.cpp the connections are the
default, so, lets suppose that sender and receiver are in the same thread.  Then, effectively, 'task.data() destroyed()' will be sent as a Qt::DirectConnection, and if this is done while control is in one event loop, while the slot TaskItem::taskDestroyed() later calls deleteLater() from another event loop, then the actual deletion will never be performed. On the other hand, if the sender and receiver are in different threads, the destroyed() signal will be sent as a Qt::QueuedConnection.  My theory is that, in this case, the slot TaskItem::taskDestroyed() will effectively get the signal as if it had been
sent from the event loop in control when the deleteLater() is made, and hence
the deletion will be performed.

If the above is correct, it would explain why the ghost entries are random, as
sometimes timing would be such that things work OK, other times not.

To test this, I used the attached patch, the key element of which is the use
of forced Qt::QueuedConnection connections for the destroyed() signal. By doing
this Qt::DirectConnection-like behaviour is not used.  PLEASE NOTE: the first
patch I submitted was an error on my part (that file didn't have the Qt::QueuedConnection in it).

In the patch also modified TaskItem::~TaskItem() and TaskItem::setTaskPointer(TaskPtr task) because the existing code looks 'race condition'-prone, but I'm unsure about this.

Here is some sample debug output (I simply inserted kDebug statements in the code):

Case 1: taskitem.cpp unmodified (except for kDebug):

Note that deleteLater() is not always called, and that TaskItem::~TaskItem is never called

New PolkitAgentListener  0x8094f50 
Adding new listener  PolkitQt1::Agent::Listener(0x814fff8) for  0x8094f50 
krunner(2356)/libplasma Plasma::Package::isValid: Could not find required file mainscript 
plasma-desktop(2343)/plasma TaskManager::TaskItem::TaskItem:  (QObject *parent, StartupPtr task)  <<-- firefox
plasma-desktop(2343)/plasma TaskManager::TaskItem::setTaskPointer:  d->startupTask != 0 
plasma-desktop(2343)/plasma TaskManager::TaskItem::setTaskPointer:  d->task.data() != task.data() 
plasma-desktop(2343)/plasma TaskManager::TaskItem::TaskItem:  (QObject *parent, StartupPtr task) <<-- okular
okular(2442)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:
okular(2442)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:
okular(2442)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:
okular(2442)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:
okular(2442)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:
plasma-desktop(2343)/plasma TaskManager::TaskItem::setTaskPointer:  d->startupTask != 0
plasma-desktop(2343)/plasma TaskManager::TaskItem::setTaskPointer:  d->task.data() != task.data() 
plasma-desktop(2343)/plasma TaskManager::TaskItem::TaskItem:  (QObject *parent, TaskPtr task)    <<-- java app
plasma-desktop(2343)/plasma TaskManager::TaskItem::taskDestroyed:  deleteLater() called 
plasma-desktop(2343)/plasma TaskManager::TaskItem::TaskItem:  (QObject *parent, StartupPtr task) <<-- konsole
plasma-desktop(2343)/plasma TaskManager::TaskItem::TaskItem:  (QObject *parent, TaskPtr task) 
plasma-desktop(2343)/plasma TaskManager::TaskItem::taskDestroyed:  deleteLater() called 


Case 2: taskitem.cpp code as is, except with destroyed() using forced Qt::QueuedConnection:

Note that deleteLater() is not always called, but that TaskItem::~TaskItem is now called

New PolkitAgentListener  0x8094f50
Adding new listener  PolkitQt1::Agent::Listener(0x815ece8) for  0x8094f50
krunner(2354)/libplasma Plasma::Package::isValid: Could not find required file mainscript
plasma-desktop(2336)/plasma TaskManager::TaskItem::TaskItem:  (QObject *parent, StartupPtr task) <-- firefox
plasma-desktop(2336)/plasma TaskManager::TaskItem::setTaskPointer:  d->startupTask != 0
plasma-desktop(2336)/plasma TaskManager::TaskItem::setTaskPointer:  d->task.data() != task.data()
plasma-desktop(2336)/plasma TaskManager::TaskItem::~TaskItem:  d deleted
plasma-desktop(2336)/plasma TaskManager::TaskItem::TaskItem:  (QObject *parent, StartupPtr task) <<-- firefox
plasma-desktop(2336)/plasma TaskManager::TaskItem::setTaskPointer:  d->startupTask != 0
plasma-desktop(2336)/plasma TaskManager::TaskItem::setTaskPointer:  d->task.data() != task.data()
plasma-desktop(2336)/plasma TaskManager::TaskItem::~TaskItem:  d deleted
plasma-desktop(2336)/plasma TaskManager::TaskItem::TaskItem:  (QObject *parent, TaskPtr task) <-- java app
plasma-desktop(2336)/plasma TaskManager::TaskItem::taskDestroyed:  deleteLater() called
plasma-desktop(2336)/plasma TaskManager::TaskItem::~TaskItem:  d deleted


Case 3: taskitem.cpp with patch: kde-workspace-4.7.2-ghost-taskbar-entries-fix.02.patch

New PolkitAgentListener  0x8094f50
Adding new listener  PolkitQt1::Agent::Listener(0x815ee48) for  0x8094f50
krunner(2358)/libplasma Plasma::Package::isValid: Could not find required file mainscript
plasma-desktop(2345)/plasma TaskManager::TaskItem::TaskItem:  (QObject *parent, StartupPtr task) <<-- firefox
plasma-desktop(2345)/plasma TaskManager::TaskItem::setTaskPointer:  d->startupTask != 0
plasma-desktop(2345)/plasma TaskManager::TaskItem::setTaskPointer:  d->task.data() != task.data()
plasma-desktop(2345)/plasma TaskManager::TaskItem::taskDestroyed:  deleteLater() called
plasma-desktop(2345)/plasma TaskManager::TaskItem::~TaskItem:  d deleted
plasma-desktop(2345)/plasma TaskManager::TaskItem::TaskItem:  (QObject *parent, StartupPtr task) <<-- okular
okular(2443)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:
okular(2443)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:
okular(2443)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:
okular(2443)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:
okular(2443)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:
plasma-desktop(2345)/plasma TaskManager::TaskItem::setTaskPointer:  d->startupTask != 0
plasma-desktop(2345)/plasma TaskManager::TaskItem::setTaskPointer:  d->task.data() != task.data()
plasma-desktop(2345)/plasma TaskManager::TaskItem::taskDestroyed:  deleteLater() called
plasma-desktop(2345)/plasma TaskManager::TaskItem::~TaskItem:  d deleted

(In reply to comment #52)
> Which QTimers are you referring to? The KDE patch does not use QTimers - but
> they are mentioned in the email thread (by me).
My mistake, sorry.
> 
> In my IconTasks fork I connect the deleteLater's to QTimers, as otherwise I do
> not see the destructors being called. (And I also observed this with the KDE
> taskbar)
> 
> Are you saying with your patch that the destructors get called? I tested by
> adding a qDebug call (printing out the value of the item pointer) before the
> deleteLater call, and in the items destructor. Without using the QTimers, the
> destructor was not being called. Admittedly the QTimer addition is just  a
> hack, and the real reason as to why deleteLater items are not being destroyed
> need to be found.
Yes, destructors get called (see Comment #55)

Created attachment 64534 [details]
ghost taskbar entries patch (final)

Thinking more about my 'suspicions' about a 'race condition', I think I'm incorrect (I was mixing up TaskItem and task.data() objects), that part of the code is probably OK. So this (final) patch simply adds the Qt::QueuedConnection ConnectionTypes to the connection statements.
Sorry, my bad.

Just tried your patch, and the TaskManager::TaskItem does seem to get deleted using deleteLater with this patch. However, I'm still seeing TaskManager::TaskGroup and AbstractTaskItem (in the applet) that are marked deleteLater not actually being deleted.

Have you tried looking at these two classes as well???

(In reply to comment #58)
> Just tried your patch, and the TaskManager::TaskItem does seem to get deleted
> using deleteLater with this patch. However, I'm still seeing
> TaskManager::TaskGroup and AbstractTaskItem (in the applet) that are marked
> deleteLater not actually being deleted.
> 
> Have you tried looking at these two classes as well???

Not yet. I was worried about those as well because of the deleteLater() calls there. Anyway, this is not a done deal... just a little while ago I got another unremoved taskitem in the taskbar, so the issue remains. I'll continue looking at this. The problem I have now is that I recently updated the xorg video driver on my system, and with that update the ghost task items occur very rarely -- so its hard to test... I may revert the driver to help testing..

Created attachment 64562 [details]
ghost taskbar entries patch 04

Another patch; see if this fixes the TaskManager::TaskGroup and AbstractTaskItem deletion failures.

Comment on attachment 64562 [details]
ghost taskbar entries patch 04

Don't use this one... I think I may need several days, to tinker, more

Created attachment 64568 [details]
ghost taskbar entries patch 05

Ok, please try this patch to see if it fixes the issues in Comment #58. I haven't seen any problems yet.

Nope, sorry. Just tried your latest patch, same problem. Its easy enough to detect.

In applet/taskgroupitem.cpp add:
qDebug() << "deleteLater TaskItem " << (void *)this;

...just after/befrore: item->deleteLater();

Then in applet/abstracttaskitem.cpp, add a Debug() (again printing the address) in the destructor.

Likewise, in taskmanager/abstractgroupingstrategy, add a qDebug() after/before group->deleteLater(), and in taskmamanger/taskgroup.cpp add a Debug()  in the destructor.

Start the tasks applet in plasmoidviewer (plasmoidviewer tasks). Start a kcalc, and close it. You will not see the AbstractTaskItem being destroyed. Start two kcalcs, and then close one (which will cause a task group to be created, and then closed (depending upon the grouping settings)), and again you can see that the TaskGroup destructor is not called.

Created attachment 64578 [details]
ghost taskbar entries patch 06

I almost submitted the last patch with an additional change (in plasma/desktop/applets/tasks/taskgroupitem.cpp), but decided it was unnecessary; perhaps it is after all. So, try this one.

However, even with patch 05, I'm not seeing what you describe. I see all of:
  AbstractTaskItem::~AbstractTaskItem,
  TaskManager::TaskItem::~TaskItem, and
  TaskManager::TaskGroup::~TaskGroup:

I have attached separately a plasmoidviewer log from this patch 06

Created attachment 64579 [details]
plasmoidviewer log for patch 06

Created attachment 64589 [details]
ghost taskbar entries patch 07

Hmmm... Odd, even with patch 06 I still did not see TaskGroup being deleted *immediately*. Even in your output it would appear as if the destructors are called when plasmoidviewer terminates - which is what I've seen before. So, perhaps you were mistaken?

To have TaskGroup deleted properly, I had to add the "Qt::QueuedConnection" to the "checkGroup()" connection in abstractgroupingstrategy.cpp

The attached patch shows my changes, it also contains the debug output - and I've added QTime so that its obvious *when* a function is called.

Created attachment 64614 [details]
plasmoidviewer log for patch 06 w/Qtdebug

This is a log for patch 06, with your QtDebug from attachment (id=64589).

Created attachment 64615 [details]
plasmoidviewer log for patch 07 [attachment (id=64589)]

And this is an analogous log using your patch 07. Aside from some timing relationships, and some possible redundancies (?), they look the same. The logs have some notes I put in linking addresses and line #s in the log.

(In reply to comment #66)
> Created an attachment (id=64589) [details]
> ghost taskbar entries patch 07
> 
> Hmmm... Odd, even with patch 06 I still did not see TaskGroup being deleted
> *immediately*. Even in your output it would appear as if the destructors are
> called when plasmoidviewer terminates - which is what I've seen before. So,
> perhaps you were mistaken?

I don't think so. The plasmoidviewer log I submitted was the first time I used it for tests. What I've been doing is simply lauching apps, and then in a konsole looking at ~/.xsession-errors. Here's a sample from .xsession-errors, where I launch firefox, and then, after 5 seconds or so, close it:

.xsession-errors immediately after launch:
plasma-desktop(2348)/plasma TaskManager::TaskItem::TaskItem:  (QObject *parent, StartupPtr task) 0x8d3b360
plasma-desktop(2348)/plasma TaskGroupItem::itemRemoved:  deleteLater TaskItem 0x8466f90
plasma-desktop(2348)/plasma TaskGroupItem::itemRemoved:  deleteLater TaskItem 0x8466f90
plasma-desktop(2348)/plasma AbstractTaskItem::~AbstractTaskItem: 0x8c80c90
plasma-desktop(2348)/plasma AbstractTaskItem::~AbstractTaskItem: 0x8c8e530

.xsession-errors immediately (< 1/2 sec) after launch:
plasma-desktop(2348)/plasma TaskGroupItem::itemRemoved:  deleteLater TaskItem 0x8466f90
plasma-desktop(2348)/plasma TaskGroupItem::itemRemoved:  deleteLater TaskItem 0x8466f90
plasma-desktop(2348)/plasma AbstractTaskItem::~AbstractTaskItem: 0x8b9bfe8
plasma-desktop(2348)/plasma TaskManager::TaskItem::~TaskItem: 0x8d3b360
plasma-desktop(2348)/plasma TaskGroupItem::itemRemoved:  deleteLater TaskItem 0x8c9d758
plasma-desktop(2348)/plasma TaskGroupItem::itemRemoved:  deleteLater TaskItem 0x8c9d758
plasma-desktop(2348)/plasma TaskManager::TaskGroup::~TaskGroup: 0x8c92c10
plasma-desktop(2348)/plasma AbstractTaskItem::~AbstractTaskItem: 0x8c9d758
plasma-desktop(2348)/plasma AbstractTaskItem::~AbstractTaskItem: 0x8c9b430
plasma-desktop(2348)/plasma AbstractTaskItem::~AbstractTaskItem: 0x8cae888

I actually get this same output with patch 03, 05, and 06.

At this point, let me briefly explain my environment and a bit of history:

I don't use a distro now, but rather build all packages (approx. 900 packages)... don't ask me why ...and have been doing so for 4 years now.

Currently, my systems are gnu linux/i686 with linux-3.0.3, glib-2.14, and gcc-4.6.1. I'm using Qt-4.7.4, unpatched (ie, not using qt-core from kde). I'm using xorg-server-1.11.1, along with xorg individual tree packages, as needed.

I first noticed frequent, random  'ghost' taskbar entries with kde-4.7.0 with Qt-4.7.3, most often with gtk-based apps like audacity, firefox, and thunderbird, say, one occurrence every 2-3 launches.

In going to kde-4.7.1, the frequency dropped to say one occurrence every 10 launches.

In going to kde-4.7.2 and Qt-4.7.4, the frequency dropped again, to say one occurrence every couple of hours.

In updating the xorg video driver, the issue has very nearly disappeared, but still occurs occasionally, say, once every 1-3 days.

In all of the above cases, occurrence was more likely when an app was left open, but inactive for some time ( > 5 minutes) before closing, ie, opening an app and then closing it within 10 sec, rarely resulted in ghost entries.

At this point, I'm starting again to lean toward suspecting an xorg issue, rather than kde. For one, xorg-server-1.10+ has yet to become as stable as xorg-server-1.9.5 (or perhaps external packages have yet to sync up to it), and, second, the code changes in my patches would also apply to kde-4.6.5 (at least the Taskitem changes), and with kde-4.6.5 the issue was absent.


> 
> To have TaskGroup deleted properly, I had to add the "Qt::QueuedConnection" to
> the "checkGroup()" connection in abstractgroupingstrategy.cpp
> 
> The attached patch shows my changes, it also contains the debug output - and
> I've added QTime so that its obvious *when* a function is called.

Looks fine to me. See comments #67/68 for some new logs.

In reply to comments 67 and 68, they are *not* the same.

Log for for 67 has:
QTime("19:20:50") virtual void TaskManager::AbstractGroupingStrategy::closeGroup(TaskManager::TaskGroup*) deleteLater 0x8212b78
...
QTime("19:21:36") virtual TaskManager::TaskGroup::~TaskGroup() 0x8212b78 

So that TaskGroup destructor is *not* called until plasmoidviewer is closing down.


Log 68 has:
QTime("18:36:27") virtual void TaskManager::AbstractGroupingStrategy::closeGroup(TaskManager::TaskGroup*) deleteLater 0x821f3d8 
...
QTime("18:36:27") virtual TaskManager::TaskGroup::~TaskGroup() 0x821f3d8 

Here the destructor is called much sooner - probably at the next even loop iteration. This is why I added the QTime output, so that you can tell *when* the destructor is called.

-------

I'm of the opinion that using Qt::QueuedConnection is /probably/ less hacky than calling QTimer::singleShot(deleteLater()). However, I'm still uneasy about the need for all this.

(In reply to comment #70)
> In reply to comments 67 and 68, they are *not* the same.
> 
> Log for for 67 has:
> QTime("19:20:50") virtual void
> TaskManager::AbstractGroupingStrategy::closeGroup(TaskManager::TaskGroup*)
> deleteLater 0x8212b78
> ...
> QTime("19:21:36") virtual TaskManager::TaskGroup::~TaskGroup() 0x8212b78 
> 
> So that TaskGroup destructor is *not* called until plasmoidviewer is closing
> down.
> 
> 
> Log 68 has:
> QTime("18:36:27") virtual void
> TaskManager::AbstractGroupingStrategy::closeGroup(TaskManager::TaskGroup*)
> deleteLater 0x821f3d8 
> ...
> QTime("18:36:27") virtual TaskManager::TaskGroup::~TaskGroup() 0x821f3d8 
> 
> Here the destructor is called much sooner - probably at the next even loop
> iteration. This is why I added the QTime output, so that you can tell *when*
> the destructor is called.
> 
> -------
> 
> I'm of the opinion that using Qt::QueuedConnection is /probably/ less hacky
> than calling QTimer::singleShot(deleteLater()). However, I'm still uneasy about
> the need for all this.

I'm very uneasy about this as well.  Actually, currently, I feel QTimer::singleShot is the better of the two because using the default Qt::ConnectionType is a more internally flexible way of doing the connections (letting Qt decide when to do direct versus queued). In particular, forcing a Qt::QueuedConnection when one isn't needed might even incur a performance hit, or worse, regressions elsewhere down the road.

My current thinking as follows:

A deleteLater() call is done under control of some event loop. A deferred deletion is then performed some time later while under the control of the same event loop.

If one stays in the event loop in control when deleteLater() is called, the deferred deletion will occur. If one leaves this event loop, then the deferred
deletion will occur if and when control returns to it. If control never returns
to deleteLater() event loop, then the deferred deletion will not be performed.

Since the default Qt::ConnectionType behaves like Qt::DirectConnection if sender
and receiver are in the same thread, and like Qt::QueuedConnection if they are in different threads, and since Qt::QueuedConnection appears to work, it must be that in some cases Qt::DirectConnection behaviour fails. So it must be that in some cases when sender and receiver are in the same thread, the deleteLater() call is done while in an event loop which is then left (before Qt gets around to doing the deferred deletion) and never returned to.

So, anything that ensures that we either remain in, or return to the event loop from which the deleteLater() call is made will fix this issue.

I think both QTimer::singleShot and Qt::QueuedConnection work because they end up ensuring (or at least increasing the likelihood) that the deleteLater calls are done in an event loop that remains in control or returns to control.

However, I'm not sure at all why this would be happening. Why would deleteLater() be called from a disappearing event loop? If you launch a gui app, I assume when you click on 'close', at the instant the app closes, the apps event loop is in control, but above that, one of kde's has to get control, and from there we get destroyed() sent from the task.data() destructor (from Qt I assume) which is received by a slot in taskmanager code. It is only the event loop when deleteLater() is called that matters, so it would seem that a taskitem object lives in a perishing event loop. I don't know kde internals at all, so I don't know if this makes any sense. 
 
Anyway, if this is correct, then the problem lies upstream, eg, wherever TaskPtr's are managed (kdelibs?), and not in taskmanager code. A proper fix might then be to replace taskitem's deleteLater() with a signal sent upstream to a slot which then does the actual taskitem.deleteLater().

Also, if you look at the corresponding code in kde-4.6.5, the changes made in going to kde-4.7.2 don't appear to be enough to produce this issue, but kde-4.6.5 definitely did not suffer from this problem. So, again I'm inclined to think the root cause is outside of taskmanager code.

Um.. sorry to be whiny but this bug has survived embarassingly long given its severity. 4.7.3 was just released and this still isn't on the fix list :-S

A "workaround" to get rid of the annoying empty entries is to `killall -SIGSEGV plasma-desktop` and let it autorestart.

(In reply to comment #73)
> A "workaround" to get rid of the annoying empty entries is to `killall -SIGSEGV
> plasma-desktop` and let it autorestart.


comment #29 and #45 have better and less harassing workarounds, anyways this bug is still annoying!

On 11/03/2011 05:28 AM, Martin Pärtel  wrote:
> https://bugs.kde.org/show_bug.cgi?id=275469
>
>
>
>
>
> --- Comment #72 from Martin Pärtel<martin partel gmail com>   2011-11-03 10:28:00 ---
> Um.. sorry to be whiny but this bug has survived embarassingly long given its
> severity. 4.7.3 was just released and this still isn't on the fix list :-S
>

Is it getting to the point with KDE 4 that the left hand doesn't know 
what the right hand is doing?  TDE is looking more appealing all the 
time.  :(

(In reply to comment #74)
> 
> comment #29 and #45 have better and less harassing workarounds, anyways this
> bug is still annoying!

For some reason, neither works for me. At least the invisible kind of entry I got atm won't go away with those methods. Kubuntu 11.10 / KDE 4.7.2

Does it go away if you start a new application? If so, can you try IconTasks (http://kde-look.org/content/show.php/Icon+Tasks?content=144808). This will have the same error, as it based upon the same code. However, it has a 'Refresh' entry in the applet's right-click menu. It would be nice to know if this clears the stuck window.

I tried to investigate this issue with John Stanley. He even ran icewm and plasma's taskbar at the same time, and observed the issue with *both* of them.

I don't think the issue is in either the taskmanager library or the applet, but somewhere lower down in the stack. From my investigations with John, we found that the taskmanagey library for some reason was not being informed when a window was removed.

The 'Refresh' entry in IconTasks fakes starting of a new app by creating a window, and hiding it after 25ms. This should cause the underlying stuff to refresh the list of windows - and the stuck entry is removed. This is only a workaround though.

(In reply to comment #77)
> Does it go away if you start a new application? If so, can you try IconTasks
> (http://kde-look.org/content/show.php/Icon+Tasks?content=144808). This will
> have the same error, as it based upon the same code. However, it has a
> 'Refresh' entry in the applet's right-click menu. It would be nice to know if
> this clears the stuck window.
> 
> I tried to investigate this issue with John Stanley. He even ran icewm and
> plasma's taskbar at the same time, and observed the issue with *both* of them.
> 
> I don't think the issue is in either the taskmanager library or the applet, but
> somewhere lower down in the stack. From my investigations with John, we found
> that the taskmanagey library for some reason was not being informed when a
> window was removed.
> 
> The 'Refresh' entry in IconTasks fakes starting of a new app by creating a
> window, and hiding it after 25ms. This should cause the underlying stuff to
> refresh the list of windows - and the stuck entry is removed. This is only a
> workaround though.
yes, it goes away if you start a new application.

(In reply to comment #77)
> Does it go away if you start a new application? 

For me, no. Once they appear I haven't seen them ever spontaneously disappear and I open and close quite a lot of windows, occasionally also from the K-menu.

Removing the task manager applet from the panel and adding it back was the fix I used before discovering the more satisfying killall plasma-desktop method. For the record my task manager settings are [force row settings], [maximum rows: 2], [do not group], [only show from current screen] and [only show from current desktop].

Ah, this time opening the K-menu DID help clear out VISIBLE dead entries. It however still fails to clear invisible entries on another desktop.

Could everyone seeing 'ghost' taskbar entries report the version of Qt and X they are using ? (eg, use X -version, and qmake -v).
thanx

(In reply to comment #81)
> Could everyone seeing 'ghost' taskbar entries report the version of Qt and X
> they are using ? (eg, use X -version, and qmake -v).
> thanx

Here're mine:

$ X -version
X.Org X Server 1.10.1
Release Date: 2011-04-15
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.24-28-server i686 Ubuntu
Current Operating System: Linux thinkrock 2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11 03:31:50 UTC 2011 i686
xorg-server 2:1.10.1-1ubuntu1.3

$ qmake -v 
QMake version 2.01a
Using Qt version 4.7.2 in /usr/lib

X: X.Org X Server 1.11.1.902
Qt: version 4.7.4

X.Org X Server 1.11.1.902 (1.11.2 RC 2)

Using Qt version 4.8.0 in /usr/lib
but Qt 4.7.4 had the same problem.

$ X -version

X.Org X Server 1.10.4
Release Date: 2011-08-19
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.39-gentoo-r3 x86_64 Gentoo
Current Operating System: Linux naboo 3.0.6-gentoo #1 SMP Mon Oct 17 07:19:10 MDT 2011 x86_64
Kernel command line: root=/dev/sda3 
Build Date: 19 October 2011  07:06:46AM
 
Current version of pixman: 0.22.2
        Before reporting problems, check http://wiki.x.org
        to make sure that you have the latest version.
$ qmake -v
QMake version 2.01a
Using Qt version 4.7.2 in /usr/lib64/qt4

$ X -version

X.Org X Server 1.10.4
Release Date: 2011-08-19
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.24-29-server x86_64 Ubuntu
Current Operating System: Linux CompuPlex 3.0.0-12-generic #20-Ubuntu SMP Fri Oct 7 14:56:25 UTC 2011 x86_64
Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.0.0-12-generic root=UUID=866ef48d-28e0-4b4d-b70b-fe1bbc29b859 ro quiet splash vt.handoff=7
Build Date: 19 October 2011  05:21:26AM
xorg-server 2:1.10.4-1ubuntu4.2 (For technical support please see http://www.ubuntu.com/support) 
Current version of pixman: 0.22.2
        Before reporting problems, check http://wiki.x.org
        to make sure that you have the latest version.

$ qmake -v
QMake version 2.01a
Using Qt version 4.7.4 in /usr/lib/x86_64-linux-gnu

$ X -version

X.Org X Server 1.10.4
Release Date: 2011-08-19
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.24-29-server i686 Ubuntu
Current Operating System: Linux tnorris-laptop 3.0.0-12-generic #20-Ubuntu SMP Fri Oct 7 14:50:42 UTC 2011 i686
Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.0.0-12-generic root=UUID=125237ca-3461-4213-9cfe-534cc250025b ro quiet splash vt.handoff=7
Build Date: 19 October 2011  05:09:41AM
xorg-server 2:1.10.4-1ubuntu4.2 (For technical support please see http://www.ubuntu.com/support) 
Current version of pixman: 0.22.2
        Before reporting problems, check http://wiki.x.org
        to make sure that you have the latest version.
$ konqueror --version
Qt: 4.7.4
KDE Development Platform: 4.7.2 (4.7.2)
Konqueror: 4.7.2 (4.7.2)

Same as comment #86.

X 1.11.1.902 (1.11.2 RC 2)
Qt 4.7.4
KDE 4.7.2

openSUSE 11.4 for x86_64 with latest KDE 4.7.2 from openSUSE build service.

$ X -version

X.Org X Server 1.9.3
Release Date: 2010-12-13
X Protocol Version 11, Revision 0
Build Operating System: openSUSE SUSE LINUX
Current Operating System: Linux XXXXXX 2.6.37.6-0.7-desktop #1 SMP PREEMPT 2011-07-21 02:17:24 +0200 x86_64
Kernel command line: init=/bin/systemd root=/dev/sda2 resume=/dev/sda1 splash=silent quiet vga=0x345
Build Date: 07 June 2011  02:49:07AM
 
Current version of pixman: 0.23.6
        Before reporting problems, check http://wiki.x.org
        to make sure that you have the latest version.

$ qmake -v
QMake version 2.01a
Using Qt version 4.7.4 in /usr/lib64

~> X -version

X.Org X Server 1.10.4
Release Date: 2011-08-19
X Protocol Version 11, Revision 0
Build Operating System: openSUSE SUSE LINUX
Current Operating System: Linux linux-gcrz.site 2.6.37.6-53-desktop #1 SMP PREEMPT 2011-09-08 21:53:36 +0200 x86_64
Kernel command line: init=/bin/systemd root=/dev/disk/by-id/ata-WDC_WD2500BEVT-75ZCT2_WD-WXEY08VVE179-part2 resume=/dev/disk/by-id/ata-WDC_WD2500BEVT-75ZCT2_WD-WXEY08VVE179-part1 splash=silent quiet vga=0x317
Build Date: 28 October 2011  01:10:44PM
 
Current version of pixman: 0.22.0
        Before reporting problems, check http://wiki.x.org
        to make sure that you have the latest version.

$ X -version
X.Org X Server 1.10.4
Release Date: 2011-08-19
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.24-29-server x86_64 Ubuntu
Current Operating System: Linux Inspiron-530 3.0.0-13-generic #22-Ubuntu SMP Wed Nov 2 13:27:26 UTC 2011 x86_64
Kernel command line: BOOT_IMAGE=/vmlinuz-3.0.0-13-generic root=UUID=eca73a06-bdd2-4fb6-a92c-2160b5239262 ro splash vga=789 quiet splash vt.handoff=7
Build Date: 19 October 2011  05:21:26AM
xorg-server 2:1.10.4-1ubuntu4.2 (For technical support please see http://www.ubuntu.com/support) 
Current version of pixman: 0.22.2
        Before reporting problems, check http://wiki.x.org
        to make sure that you have the latest version.

$ qmake -v
QMake version 2.01a
Using Qt version 4.7.4 in /usr/lib/x86_64-linux-gnu

X.Org X Server 1.9.3
Release Date: 2010-12-13
X Protocol Version 11, Revision 0
Build Operating System: openSUSE SUSE LINUX

QMake version 2.01a
Using Qt version 4.8.0 in /usr/lib64

With qt 4.8 the issue is visible more often than with 4.7.x

This bug should be marked as a blocker for any future KDE releases.

On Sat, Nov 5, 2011 at 02:01, Hrvoje Senjan <hrvoje.senjan@gmail.com> wrote:
> https://bugs.kde.org/show_bug.cgi?id=275469
>
>
>
>
>
> --- Comment #93 from Hrvoje Senjan <hrvoje senjan gmail com>  2011-11-05 07:00:58 ---
> X.Org X Server 1.9.3
> Release Date: 2010-12-13
> X Protocol Version 11, Revision 0
> Build Operating System: openSUSE SUSE LINUX
>
> QMake version 2.01a
> Using Qt version 4.8.0 in /usr/lib64
>
> With qt 4.8 the issue is visible more often than with 4.7.x
>
> --
> Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.
>

Ok, enough version info; I was kinda hoping there would be clear distinction between xorg-server-1.9.x and xorg-server-1.10+; doesn't look to be the case.

For anyone having the problem and able to re-build kde-workspace (just keep a tree around, and it takes only a couple of minutes to rebuild), try rebuilding (v4.7.3) with the patches at:

https://projects.kde.org/projects/kde/kde-workspace/repository/revisions/0f40b5772e6e8c6044fa4605ae7f16eb83c2ce68

and/or:

https://projects.kde.org/projects/kde/kde-workspace/repository/revisions/52783c6c024b9299708a713c8eebf8dc8a69f63b

These patches suggest the problem is in Qt, and "may" provide a workaround. I say "may" here because from my investigations the issue they directly address may actually be unrelated to the "ghost" taskbar entries... Would be nice if someone who has the issue frequently could try the patches. Its very hard for me to do this because w/kde-4.7.3 for 3 days now, I haven't seen a single "ghost" entry...

thanx all

I have yet to see this problem in KDE 4.7.3. I had previously been getting this problem with Firefox almost constantly with KDE 4.7.2.

I still have this problem in Kubuntu 11.10 KDE 4.7.3

Ya, the problem still exists in 4.7.3. If I use Firefox for a long enough time, then close it, it stays in the taskbar. I have my taskbar on autohide, and if you let the taskbar go down to the bottom, then bring it back up, the window is gone.

It's resolved in 4.8. 

Read the section on 'Taskbars, Docks and libtaskmanager' in following blog post by a KDE developer.

Sorry for missing link. Here it is:
http://aseigo.blogspot.com/2011/11/plasma-workspaces-48.html

(In reply to comment #99)
> It's resolved in 4.8. 
> 
> Read the section on 'Taskbars, Docks and libtaskmanager' in following blog post
> by a KDE developer.

(In reply to comment #100)
> Sorry for missing link. Here it is:
> http://aseigo.blogspot.com/2011/11/plasma-workspaces-48.html
> 
> (In reply to comment #99)
> > It's resolved in 4.8. 
> > 
> > Read the section on 'Taskbars, Docks and libtaskmanager' in following blog post
> > by a KDE developer.

Actually, the 'fix' mentioned there is for a possibly related issue, but does not fix the 'ghost' entries; this I have verified myself.

I'd also like to mention that kde-4.7.3 with the 4.8 patches has actually increased the frequency of occurrence of the ghost entries..., for me, kde-4.7.2 is much better in this respect.

K. Thanks for the info.

Confirming this bug exists in 4.7.3 as well, I have desktop effects disabled so I'm pretty sure it's not related to that at all.  If I open the launcher or start another program when I have a 'phantom' taskbar entry it usually goes away on it's own.  But until then it's pretty annoying for it to still show an entry for an application that's been closed already, this just started happening recently for me, unfortunately I can't pinpoint any specific pakage installation that may have triggered it since I just installed 11.10 recently (clean install) and have been on a 'install spree' installing all the packages I used to use on 10.10.  But I sure hope this gets fixed soon.

I can confirm, kde 4.7.2

I have this bug too (Kde 4.7.3, archlinux x86_64)

Ok guys I think is better to stop spamming everyone with more not so useful comments, the bug is present in all KDE 4.7.x, this is KNOWN so either you try 4.8 and report here your findings or wait that someone else do it.

Thank you.

Hi,
I'd be nice if this were actually fixed, but I fear not. If you are 
basing this on the patches from:

Revision: 0f40b577
     libs
         taskmanager
             taskitem.cpp (diff)
             taskmanager.cpp (diff)
https://projects.kde.org/projects/kde/kde-workspace/repository/revisions/0f40b5772e6e8c6044fa4605ae7f16eb83c2ce68


Revision: 52783c6c
      libs
         taskmanager
             abstractgroupingstrategy.cpp (diff)
             taskitem.cpp (diff)


https://projects.kde.org/projects/kde/kde-workspace/repository/revisions/52783c6c024b9299708a713c8eebf8dc8a69f63b

then it is in fact not fixed. The deleteLater() issue and the 'ghost' 
entry issue are not directly related. The 'ghost'
entries occur whether or not the deleteLater() issue has been mended. 
The patches above address the deleteLater()
issue, but not the 'ghost' entry problem. In emails I sent to Craig 
Drummond, I thought this point was clear.

The ghost entries occur if 'tasks' is running in a panel, or on the 
desktop. However, if you run 'plasmoidviewer tasks'
in a konsole, the ghost entries do not occur in the 'plasmoidviewer 
tasks' GUI, but still occur in the panel (and desktop)
'tasks'. My conclusion from this (and from my debug investigations which 
I sent to Craig), is that the ghost issue
appears not to be due to 'tasks' (and likely, libtaskmanager) code, but 
to some problem in plasma-desktop itself,
or kdelibs.

I've attached a short log (.xsessions-errors) showing some debug output 
for a ghost entry occurrence (in this log
do a find on 'GHOST'). The issue then is this: randomly, and on my 
systems, quite infrequently, the X ClientList
propertyChange event for the running "plasma-desktop" instance simply 
doesn't occur (or is prematurely consumed).
Note that this event does occur for other objects such as kwin, konsole, 
kmix, etc., so the problem appears not to
be in X (or Qt) itself. The problem would appear to be in 
plasma-desktop, or in how plasma-desktop is
associated/interfaced to KWindowSystem or kinit... However, I'm not sure 
here as I don't know kde internals at all.

The fact the the ghost entries DO NOT occur when 'tasks' is run under 
plasmoidviewer, but do occur when run under
plasma-desktop would seem significant. Could it be that one of the other 
apps (such as kded, konsole, etc) running
under kinit is, on occasion eating the ClientList event, prior to it 
being passed to plasma-desktop ?

Finally, please note that this is timing-related, on my systems, the 
ClientList event does occur correctly 99+ %  of
the time. Simply changing the debug I print changes the frequency of 
ghost occurrences.
John





On 11/23/2011 12:19 PM, Aaron J. Seigo wrote:
> https://bugs.kde.org/show_bug.cgi?id=275469
>
>
> Aaron J. Seigo<aseigo@kde.org>  changed:
>
>             What    |Removed                     |Added
> ----------------------------------------------------------------------------
>               Status|NEW                         |RESOLVED
>           Resolution|                            |FIXED
>
>
>
>

Just wanna make an additional point (I forgot in my previous email): the 
same bug which
is responsible for the ghost taskbar entries (ie, the missing ClientList 
propertyChange event)
also manifests itself (on occasion) in a different way when launching an 
app. Sometimes when
launching an app by clicking on a launcher in the bottom panel, the app 
starts OK, but no
taskitem taskbar entry appears. Then, say 10 seconds later, or several 
minutes later, launch
another app, and hey,  the 'missing' taskitem taskbar entry appears 
(along with that of the
second app).

The root problem here is the same: a ClientList propertyChange event was 
not delivered to
the plasma-desktopinstance for the first app (hence addClient() was 
never called), but, on
launching the second app, the associated ClientList propertyChange event 
is delivered and
the hence addClient() calls are then done for both apps.
John


On 11/23/2011 12:19 PM, Aaron J. Seigo wrote:
> https://bugs.kde.org/show_bug.cgi?id=275469
>
>
> Aaron J. Seigo<aseigo@kde.org>  changed:
>
>             What    |Removed                     |Added
> ----------------------------------------------------------------------------
>               Status|NEW                         |RESOLVED
>           Resolution|                            |FIXED
>
>
>
>

Still there is latest 4.7 git branch. It happens much less often though.
I got a kmail window that I could now minimize.

In case you wondered, i installed kde 4.8 beta1 and the problem is present in it too.

It is seeming as if this bug may be marked as RESOLVED/FIXED, when indeed it is not fixed at all. For such a long-lived and significant bug, it would be tragic were it to still be an issue when 4.8 is released.

Reportedly not fixed, reopening.

Any update about this annoying bug? 

Aaron J. Seigo maked it as fixed, but I can confirm that it is still present in Kubuntu 11.10 KDE 4.7.4

It still happens in 4.8 beta2 (32-bit openSUSE 12.1).

This is still here for me with 4.7.95 (RC1).

(In reply to comment #116)
> This is still here for me with 4.7.95 (RC1).

With ArchLinux btw

This bug needs very high severity and needs to be a release blocker.

(In reply to comment #118)
> This bug needs very high severity and needs to be a release blocker.

Agreed FWIW. Would be embarassing if this ended up in another round of distros.

Judging from earlier discussion this is a real pain to debug and even significant investigation didn't lead to a fix. It seems to me that if this isn't explicitly prioritized, it's unlikely anyone will want to pick it up "voluntarily". I know I wouldn't :)

I have the problem too with 4.8 RC1. I agree that it needs high severity and to be considered a release blocker.

4.7.4 opensuse 12.1 - I still have this bug . 
It seems it's somehow related to high memory usage( memory leak ? )  of plasma-desktop . 
Using xrestop I can see that when plasma-desktop crosses 20-22 MB of memory total usage - bad things start to happen ( ghost closed windows on taskbar , slow or even no response on clicks on taskbar , etc )

I believe I have the fix. Qt is the culprit. Is there anyone out there who is reasonably often having the ghost entry issue, and can re-build Qt to see if it fixes the problem?  Re-building it from scratch is a pita as it takes a long time (3-4 hours on my PC), but once you have the build tree, re-building is a snap, about a minute. I can supply a patch, and I'm submitting it to Nokia.

Anyway the problem is caused by Qt not delivering a ClientListNotify XEvent, when it does mouse-move compression.  The issue applies to a large class of XEvents, not just ClientListNotify's.

Yes, I can try the Qt patch if you upload it here. I can report if it fixes the problem. I am running Qt 4.8 right now.

I will try it too, I have ghost entries almost every day.

Eeeeenteresting...  Since John Stanley mentioned the relationship between mouse movement and this bug, I have found a way to reproduce this bug very easily.  I do this test with Firefox, since it seems to get more easily "stuck" in the taskbar, for some reason.  Here is how:

1) Close all applications and open Firefox.
2) Close Firefox by clicking on the window manager close button (X), but make sure your mouse doesn't move at all in the process.  Firefox should close cleanly without any ghost entries.
3) Now, start Firefox again.
4) Close Firefox using the same button, but try to move the mouse very quickly to and from the button while pressing it.  On my system, I get a ghost entry almost every time I do this.

I hope this helps you testers out there.  Once I am back home in a couple of days, I will also try building Qt with the patch to test.

I should add that it's more about the quick mouse movement during/after the button click than before, so that should make it easier to aim for the button :)

Christian, that really helped me reproducing the problem. I see ghost Firefox taskbar button usually too and my use case is closing the last opened window by mouse gesture - down and right while holding the right mouse button. I tried to move the mouse out of the window after the gesture and I got the ghost button immediately.

(In reply to comment #125)
> Eeeeenteresting...  Since John Stanley mentioned the relationship between mouse
> movement and this bug, I have found a way to reproduce this bug very easily.  I
> do this test with Firefox, since it seems to get more easily "stuck" in the
> taskbar, for some reason.  Here is how:
> 
> 1) Close all applications and open Firefox.
> 2) Close Firefox by clicking on the window manager close button (X), but make
> sure your mouse doesn't move at all in the process.  Firefox should close
> cleanly without any ghost entries.
> 3) Now, start Firefox again.
> 4) Close Firefox using the same button, but try to move the mouse very quickly
> to and from the button while pressing it.  On my system, I get a ghost entry
> almost every time I do this.
> 
> I hope this helps you testers out there.  Once I am back home in a couple of
> days, I will also try building Qt with the patch to test.

Thanks. Now I can reproduce this bug easily too with every application (system settings, dolphin etc). So I can confirm that your method works :)

I can really easily reproduce it now. 
http://i.imgur.com/iqHNo.png

Could you post the patch here? 

Since I am on gentoo, I have to compile Qt by myself anyway, and I can do it in the process of updating to 4.8. 

I am currently on vacation, but I will try to give feedback as soon as possible. 

Thanks, kind regards

I can confirm Christian's observation on my KDE 4.7.4, too. The cursor movement before the click seems completely irrelevant. Quick movement during or after the click, however, always causes a ghost entry.

Besides, I can only reproduce the bug with one window opened. It does not appear when there is more than one taskbar entry. 
When I restart the program which left the ghost entry, the ghost entry is replaced by the correct new entry.

You guys are right. I just open and closed KDiskFree, and when I closed it I yanked the mouse cursor away from the "x" as fast as I could, and it created the ghost entry. Good job!

Created attachment 67167 [details]
Patch to fix Qt issue which causes taskbar ghost entries

Created attachment 67168 [details]
Patch to fix Qt issue which causes taskbar ghost entries

This is for Qt-4.8.0 (the previous for Qt-4.7.4), but its only 2 lines of code, so the patches are essentially the same; either will work for both versions of Qt.

I just recompiled Qt 4.7.4 with the patch, and so far I was not able to reproduce the problem. 

It might require some more testing, but so far it looks good. Thanks a lot already :)

(In reply to comment #122)
> I believe I have the fix. Qt is the culprit. Is there anyone out there who is
> reasonably often having the ghost entry issue, and can re-build Qt to see if it
> fixes the problem?  Re-building it from scratch is a pita as it takes a long
> time (3-4 hours on my PC), but once you have the build tree, re-building is a
> snap, about a minute. I can supply a patch, and I'm submitting it to Nokia.
> 
> Anyway the problem is caused by Qt not delivering a ClientListNotify XEvent,
> when it does mouse-move compression.  The issue applies to a large class of
> XEvents, not just ClientListNotify's.

If you have reported a Qt bug for this, is it possible that you can post the link here so we can CC ourselves there to keep track?

The patch fixes the problem for me (Qt 4.7.4).

(In reply to comment #136)
> (In reply to comment #122)
> > I believe I have the fix. Qt is the culprit. Is there anyone out there who is
> > reasonably often having the ghost entry issue, and can re-build Qt to see if it
> > fixes the problem?  Re-building it from scratch is a pita as it takes a long
> > time (3-4 hours on my PC), but once you have the build tree, re-building is a
> > snap, about a minute. I can supply a patch, and I'm submitting it to Nokia.
> > 
> > Anyway the problem is caused by Qt not delivering a ClientListNotify XEvent,
> > when it does mouse-move compression.  The issue applies to a large class of
> > XEvents, not just ClientListNotify's.
> 
> If you have reported a Qt bug for this, is it possible that you can post the
> link here so we can CC ourselves there to keep track?

Yes, sorry... here's the Qt bug posting:
https://bugreports.qt.nokia.com/browse/QTBUG-23361

Re the Qt bug report for this( https://bugreports.qt.nokia.com/browse/QTBUG-23361 ), I included two additional patches which take care of the problem by modifying how the mouse move compression collects events. I've tested all three, all appear to fix the issue, and there don't appear to be any performance hits.

Here are two more Qt bug posts I made (with tentative patches) which relate to the issue here:

https://bugreports.qt.nokia.com/browse/QTBUG-23369
https://bugreports.qt.nokia.com/browse/QTBUG-23390

The first one is a possible fix for the taskitem.cpp deleteLater() issue, and the second one is a possible fix for the deleteLater() issues in taskmanager.cpp and abstractgroupingstrategy.cpp (the causes of the deleteLater() problems differ).

With these two patches there is no longer a need to use singleShot QTimers in the above code... so hopefully, someday Qt will adopt the patches (or the 'proper' equivalent).

For now, the singleShot QTimers used in KDE-4.7.X works around the problem.

Ho do I remove myself from this bug's mail lists.

(In reply to comment #140)
Thanks, this patch solve this problem to me - but not in case when item on taskbar launched from clicking on application icon in tray (ktorrent for example) - window state (active/inactive/minimized) still displayed incorrectly sometimes.
Applications that launched from menu does not affected.

(In reply to comment #142)
> (In reply to comment #140)
> Thanks, this patch solve this problem to me - but not in case when item on
> taskbar launched from clicking on application icon in tray (ktorrent for
> example) - window state (active/inactive/minimized) still displayed incorrectly
> sometimes.
> Applications that launched from menu does not affected.

I'm assuming you re-built Qt with patch
    https://bugs.kde.org/attachment.cgi?id=67167
or
    https://bugs.kde.org/attachment.cgi?id=67168

What version of kde-workspace are you using, and what (if any) patches were used ?
 
thanks

(In reply to comment #143)
> What version of kde-workspace are you using, and what (if any) patches were
> used ?

Sorry, now I figured out that this behavior is related to https://bugs.kde.org/show_bug.cgi?id=275835 or https://bugs.kde.org/show_bug.cgi?id=274020 .
I use http://bugsfiles.kde.org/attachment.cgi?id=67167 patch and windows "hanging" at taskbar is not the case now - only this annoying "demand attention" keeping bug.
Thanks a lot for patches, and sorry for my bad English.

This annoying bug affects Kubuntu Oniric 11.10, with KDE 4.7.3 and QT 4.7.4. In Kubuntu it can be solved by patching a file included in libqtcore4-4.7.4 sources package.

As suggested in comment #133 by John Stanley, I've applied a reworked patch of comment #133 (adapted to ubuntu sources), recompiled the sources and the reininstall the stuff.

Now Plasma works correctly, no ghost windows anymore.

I've some trouble in *.deb creation at the end of the compilation (debuild -uc -us deads and exit with an error). So, I've installed the libqtcore4 stuff by a "sudo make install".

I hope someone can create the right Ubuntu packages.

Created attachment 67535 [details]
Patch for kubuntu 11.10 - libqtcore4 4.7.4 ubuntu sources

This is a patch for kubuntu 11.10 libqtcore4-4.7.4 sources:

mkdir work
cd work
apt-get sources libqtcore4

Then copy the patch into packagename-version/debian/patches, edit the file packagename-version/debian/patches/series by adding "closed_windows_stay_in_taskbar.patch" at the bottom.

Now you are ready to recompile:
sudo apt-get build-dep libqtcore4
debuild -us -uc

@linuxboy
lauchpad bug report: https://bugs.launchpad.net/ubuntu/+source/qt4-x11/+bug/911733

(In reply to comment #147)
> lauchpad bug report:
> https://bugs.launchpad.net/ubuntu/+source/qt4-x11/+bug/911733

thank you.

About "taskbar doesn't react on clicks"

Can anyone confirm that John Stanley's Qt patch fixes this problem?

Steps to reproduce: Click on the taskbar entry and quickly as soon as you clicked on it move mouse pointer upwards to remove it from hovering over the taskbar entry.
Video: http://www.youtube.com/watch?v=JhPIQJm4Kl0&feature=youtu.be

(In reply to comment #149)
> About "taskbar doesn't react on clicks"
> 
> Can anyone confirm that John Stanley's Qt patch fixes this problem?
> 
> Steps to reproduce: Click on the taskbar entry and quickly as soon as you
> clicked on it move mouse pointer upwards to remove it from hovering over the
> taskbar entry.
> Video: http://www.youtube.com/watch?v=JhPIQJm4Kl0&feature=youtu.be

It fixes the ghost entries for me but the taskbar still doesn't react sometimes to clicks. I have grouping set to always ("only when taskbar is full" option is disabled).

Created attachment 67567 [details]
additional Qt X11 event processing modifications for Qt-4.7.4

Created attachment 67568 [details]
Combined Qt X11 event processing modifications for Qt-4.7.4

Created attachment 67569 [details]
Additional Qt X11 event processing modifications for Qt-4.8.0

Created attachment 67570 [details]
Combined Qt X11 event processing modifications for Qt-4.8.0

Re Comment #150:

I don't see this behaviour on my system(s) so its hard for me to test, but as
I mentioned earlier, there are several other places in the Qt X11 event processing code where Qt may, under some conditions, fail to make X11 events available to KDE, very similar to the mouse MotionNotify case.

I've attached several patches for Qt-4.7.4/4.8.0 which address these additional 'problem' points in the Qt code.  I've been using these patches myself for several weeks and haven't seen any issues, so I plan to stick with them at least until Qt developers get a chance to look at the issue.

I've also added these additional code mods to
https://bugreports.qt.nokia.com/browse/QTBUG-23361.

It is possible that this fixes the 'taskbar doesn't react on clicks' problem, but as I don't see it myself, I cannot say for sure.  

I've attached the following patches:

  04-qt-opensource-4.7.4-x11-event-processing-supl.01.patch - additional mods 
  03-qt-opensource-4.7.4-x11-event-processing-mods.01.patch - combined patch

  04-qt-opensource-4.8.0-x11-event-processing-supl.01.patch - additional mods
  03-qt-opensource-4.8.0-x11-event-processing-mods.01.patch - combined patch

So, for Qt-4.7.4, use
  https://bugs.kde.org/attachment.cgi?id=67535 or
  https://bugs.kde.org/attachment.cgi?id=67167 

along with
  https://bugs.kde.org/attachment.cgi?id=67567

or use only 
  https://bugs.kde.org/attachment.cgi?id=67568

which combines everything (and similarly for Qt-4.8.0).

(In reply to comment #146)
Linuxboy, I tried patching and compiling the Kubuntu source per your instructions, but after installing the generated libqtcore4 .deb using "sudo dpkg -i", the bug still persists.  Based on all the reports of the patch working, I suspect something went wrong with the patch/build process on my PC, but I have no idea where to look for an answer.  BTW, is it possible that the build process errored out on you due to lack of disk space?  The whole process ate up almost 10 gigs of space on my PC and took hours to complete.

@John, please could you submit a merge request on gitorious and link it here? It's sometime faster than bug reports to get feedback from upstream.

(In reply to comment #157)
> @John, please could you submit a merge request on gitorious and link it here?
> It's sometime faster than bug reports to get feedback from upstream.

I will probably do a merge request this weekend, time permitting.

Here's a Qt/Gitorious link to all 4 patch/commits I hope to merge:

https://qt.gitorious.org/~jpsinthemix/qt/qt-fixes/

I haven't actually done the MR because I don't know which repo to merge to..
Waiting on email ..
John

> I haven't actually done the MR because I don't know which repo to merge to..

All changes should be submitted against Qt5 through gerrit, then backported if critical. See http://wiki.qt-project.org/Qt_Contribution_Guidelines for details.

(In reply to comment #160)
> > I haven't actually done the MR because I don't know which repo to merge to..
> 
> All changes should be submitted against Qt5 through gerrit, then backported if
> critical. See http://wiki.qt-project.org/Qt_Contribution_Guidelines for
> details.

I went through the Gerrit doc first, created an account, cloned the tree, etc., but, submitting against Qt5 is pointless (the code is vastly different, particularly w.r.t. the X11 interface; only one of my six changes are is even possibly meaningful). Further, I would/should build qt5 and verify things.. will KDE even build against Qt5? 

I think at this point I'll try to connect with someone at Qt who might be willing to move this along, but my feeling is this probably won't lead anywhere.

@ John Stanley, all

I found one more task manager bug that I think is related to this Qt bug.

Opened window is not marked on taskbar: http://www.dodaj.rs/f/Z/YG/nRwwZhS/snapshot3.png

How to reproduce: 
http://www.youtube.com/watch?v=zlfWe_CW0q8

Can anyone confirm/reproduce this?

I am seeing something like what is being reported in #162.  It appeared to start after an update yesterday or the day before of X. Given that this is likely to be a separate issue, I have opened this ticket for it:

https://bugs.kde.org/show_bug.cgi?id=292057

What a mess !

I've done a Kubuntu package update this morning. The incoming libqtcore4 with a lot of library stuff, have replaced the patched packages.

And now the bug IS STILL HERE!

Damn!

I've got the patches going through the Qt Gerrit (http://www.qt-project.org/) qt/4.8 branch.  The most important one

  http://bugsfiles.kde.org/attachment.cgi?id=67168

has been accepted by one reviewer, but all are still 'under review.'  I guess this will be a slow process.

So much for this bug getting high severity and being a release blocker. It is very understandable that this bug is a complicated one, and difficult to remedy. What is not understandable (to me) is that KDE just goes right ahead with its major releases while bugs like this continue on in perpetuity. At any rate, many thanks to the folks who have been working hard to remedy this bug.

Just putting in my 2 cents worth to point out that this bug still has not been fixed in 4.8 (32 bit at least, haven't noticed any problems in 64 bit since upgrading to 4.8).  I agree that something this major should have never been allowed to make it through to 4.8 though.  Pretty sloppy if you ask me.  While I know the reason this is happening is probably pretty complicated in itself it shouldn't be that awful hard to compare the code from the last revision that did not have this problem and then go through and try to fix it.  I mean there's only so many libraries/services that interact with the task bar (task manager plasmoid or whatever you want to call it) in a manner that could result in this behaviour.

While I would normally agree that there is no excuse to release KDE with such a bug, I'm pretty sure this time it's a Qt bug and not a KDE bug. Am I wrong? If it's a Qt bug it will be fixed in Qt. No sense holding KDE 4.8 back waiting for Qt to fix it.

I don't understand the argument of #168.  Is there no workaround to the Qt bug?  The users don't care whose fault this is, but if the taskbar is unusable it's a pretty big problem.

I haven't seen this issue on 64bit, nor have I recently seen the issue I reported in #163.

(In reply to comment #169)
> I don't understand the argument of #168.  Is there no workaround to the Qt bug?
>  The users don't care whose fault this is, but if the taskbar is unusable it's
> a pretty big problem.

KDE doesn't distribute Qt and as far as I can see, there is no reasonable workaround. While I agree the bug is very embarassing, there is nothing more they can do about it so why hold up the release? I believe the best that KDE can do right now is to advise distros to patch their Qt until a fixed version is released.

If it has been determined that opening and closing kmenu fixes the issue (see #29), then there is clearly something the taskbar can do to correct itself - whatever it is that gets done when kmenu opens and closes.  How about doing that every 15 seconds?

@ #169: I have 64 bit, and I have this issue.

Ok, with some guidance/input from Qt techs, patches have been accepted for Qt/4.8. The links are:

http://codereview.qt-project.org/13465
http://codereview.qt-project.org/13468
http://codereview.qt-project.org/14627

You may need a a Gerrit account to see/get them. They have not actually been merged yet-- Qt would like them ported to Qt/5 before merging to Qt/4.8. Hopefully, the Qt/5 port can be done within a week or two..

Patch 13465 is the most relevant to the issue here (and likely the only one needed to fix it), patch 14627 obviates the need to use single-shots for certain deletelater() calls in taskmanager code, and 13468 fixes 'possible' corner cases similar to 13465.

I can supply the current patch versions if anyone wants them, but for those who need to be more formal, I guess the above Gerrit links are the way to go.

Some thoughts:

1.  There is "always" a workaround.  Even if it meant rewriting some
code in KDE, or duplicating some functionality of Qt, of course it
could be worked around.  If there's a bug in a library that upstream
won't fix, and it's a major bug like this, it's ludicrous to not work
around it, and to keep making major releases with the bug.

2.  This is another example of KDE 4 *continuing* to shoot itself in
the foot--and people say that the 4.0 debacle is over... :( "Who's in
charge here?"  No one?  Well, someone needs to be.

3.  Apparently Nokia/Qt/whoever's in charge over there doesn't realize
how important this bug is.  It needs to be merged ASAP, regardless of
Qt5.  Distros also need to backport patches to supported versions.

Or I guess people can continue to be frustrated by KDE, further
injuring its reputation...

ad 1. It doesn't make sense to work around Qt bugs when we can fix Qt instead. I'm re-resolving the bug as UPSTREAM, i.e. a library bug.
ad 2. See 1.
ad 3. Fedora has been shipping those patches for a while. If your distro is too incompetent to do that, consider switching distro.

The source of this bug has been identified, patches have been created, and the fix will be backported. Any further bickering and complaining about this issue is an exercise in futility. If you want to continue to complain, put that energy into something that will actually help, such as filing more bugs, or coming up with cool ideas to submit to the wishlist.

Qt 4.8.1 has been released. Anyone knows if the patch which fixes this issue is included in this new release?

yes, I believe so.

With Qt 4.8.1 installed the issue seems to be gone for good! :)

still not fixed in KDE SC 4.9!!!

(In reply to comment #180)
> still not fixed in KDE SC 4.9!!!

Read the description, it's not KDE bug. What version of Qt you are using?

Ah, ok. Sorry. It's Qt 4.8.1 on Kubuntu 12.04 and KDE SC 4.9.

(In reply to comment #182)
> Ah, ok. Sorry. It's Qt 4.8.1 on Kubuntu 12.04 and KDE SC 4.9.

The problem was in Qt, and fixed in Qt-4.8.1; if you're still seeing it using Qt-4.8.1/2, then its a new issue, or something amiss with Kubuntu 12.04

I found this problem too in KDE 4.10. Task bar shows two Konsole windows, but only one Konsole windows exists. After I closed the existing Konsole window, one Konsole icon stayed in task bar. I checked with "ps aux" in Xterm, that Konsole is not started. Restarting "plasma-desktop" does not help. Restarting the whole desktop helps of course.

Expunged by KDE Sysadmin due to commercial content.