Bug 278869 - Task manager button occasionally "sticks" and won't respond to clicks
Summary: Task manager button occasionally "sticks" and won't respond to clicks
Status: RESOLVED WAITINGFORINFO
Alias: None
Product: plasma4
Classification: Plasma
Component: widget-taskbar (show other bugs)
Version: 4.8.2
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords:
: 278881 279080 279328 288116 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-07-30 17:14 UTC by S. Christian Collins
Modified: 2013-05-07 17:20 UTC (History)
19 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description S. Christian Collins 2011-07-30 17:14:32 UTC
Version:           unspecified (using KDE 4.7.0) 
OS:                Linux

Occasionally, a task manager application button (or "tab" as I've seen it called) will become unresponsive to clicks.  I have posted a video demonstrating this:
http://www.youtube.com/watch?v=tw-3q7xMQAQ

In the video I am clicking rather fast to reproduce the bug, but it has happened a few times for me during normal usage of my PC.

Reproducible: Sometimes

Steps to Reproduce:
Clicking on two or more task manager buttons enough times with the right timing (whatever that is) will trigger the bug.

Actual Results:  
The button becomes unresponsive to further clicks (left mouse-button) until a different task manager button is clicked.  The button also appears "raised", the appearance given to non-active windows, even though the window the button represents is active.

Expected Results:  
Normal behavior.
Comment 1 S. Christian Collins 2011-07-30 23:07:13 UTC
I pulled Karan Pratap Singh's comment (#22) on bug #246838, as it seems to be related to this bug rather than #246838:
------------------------
Sorry for cross posting!

I have been facing this bug too and I have sort of found out how to reproduce
it every time :D

First Please Note: A taskbar entry for a window appears smooth when it is
minimized and depressed with shadows when it is maximised...this is the
standard KDE Plasma scheme!


Well, to produce this bug all you have to do is:

1) Minimize a window( worked for kate, Quassel and Dolphin in my case! Didn't
try with other programs...)
2) You will notice that the taskbar entry is smooth, and it should be so
everything is fine till now.
3) Now 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...You
need to get the speed right, it might take a few tries for you to get the right
speed!
4) Importantly, now you will notice that the window is maximised now, but, but
its taskbar entry is not depressed( like it should be ), but is smooth...(this
is WRONG!)
5) Now no matter how much you click on this smooth task bar entry, the window
will not minimize!!!
6) There you have it folks, the bug was reproduced everytime for me.

If in case all the above seems incredulous and you are not able to reproduce
it, then put a comment here, I will make a video and add it as an attachment :)

I hope this bug gets fixed soon, as it hampers productive use of the
taskmanager!!!
Comment 2 Karan Pratap Singh 2011-07-31 10:19:47 UTC
(In reply to comment #1)
> I pulled Karan Pratap Singh's comment (#22) on bug #246838, as it seems to be
> related to this bug rather than #246838:

+1, This indeed is the same bug I was referring to!
Comment 3 ΔΔ 2011-07-31 19:41:07 UTC
Same applies here, plus sometimes when a task is closed its icon remains in the task manager, till another task opens or closes. This appears to happen independently from the plasmoid in use, applies from my experience to both the default and smooth tasks.
Comment 4 ealexp 2011-08-01 09:31:21 UTC
This happens to me too.
Comment 5 Christoph Feck 2011-08-01 23:51:59 UTC
*** Bug 278881 has been marked as a duplicate of this bug. ***
Comment 6 Aaron J. Seigo 2011-08-02 11:30:35 UTC
for those that are suffering from this, are you using an particular settings for the tasks widget, such as "only show tasks from current desktop"?
Comment 7 ealexp 2011-08-02 11:38:47 UTC
Yes, I do use the "only show tasks from current desktop" setting.
Comment 8 Hussam Al-Tayeb 2011-08-02 11:42:44 UTC
These are my settings:
http://img508.imageshack.us/img508/893/screenshot6fy.png
Comment 9 Silver Salonen 2011-08-02 12:22:37 UTC
I've turned off all the "only" settings, because I use only one desktop and one activity.
Comment 10 S. Christian Collins 2011-08-02 15:05:46 UTC
My task manager settings are thus:
Force row settings: no
Show tooltips: yes
Highlight windows: no
Maximum rows: 2
Grouping: Manually
Sorting: Manually
Only show tasks from the current screen: no
Only show tasks from the current desktop: yes
Only show tasks from the current activity: yes
Only show tasks that are minimized: no
Comment 11 Hussam Al-Tayeb 2011-08-02 16:58:03 UTC
To "unstick" a button that doesn't respond to clicks, click on another button to minimize another window the the first window will no longer be stuck and you can minimize it too.
Comment 12 ealexp 2011-08-03 10:17:48 UTC
I have some other problems with the task manager : sometimes, a window is showed as "active" (see attachment 1 [details] to see what I mean by "active") even when I go to another window (which is not showed as active).
Also, sometimes, some windows are showed as "highlighted" even when there are not (see attachment 2 [details] to see what I mean by "showed as highlighted"). Is this the same bug or should I open a new bug report ? (or two new bug reports ?)

I haven't found a way to reproduce these bugs, but they appeared more than one time.
Comment 13 Silver Salonen 2011-08-03 11:21:51 UTC
(In reply to comment #12)
> I have some other problems with the task manager : sometimes, a window is
> showed as "active" (see attachment 1 [details] to see what I mean by "active") even when
> I go to another window (which is not showed as active).
> Also, sometimes, some windows are showed as "highlighted" even when there are
> not (see attachment 2 [details] to see what I mean by "showed as highlighted"). Is this
> the same bug or should I open a new bug report ? (or two new bug reports ?)
> 
> I haven't found a way to reproduce these bugs, but they appeared more than one
> time.

I sounds very much like bug 279080. Is that it?
Comment 14 ealexp 2011-08-03 11:39:14 UTC
That's it... but it doesn't mention the case when a window is showed as "active" when it isn't.
Comment 15 Silver Salonen 2011-08-03 11:40:34 UTC
(In reply to comment #14)
> That's it... but it doesn't mention the case when a window is showed as
> "active" when it isn't.

Hmm.. so is it related to Tark Manager plasmoid at all then? Maybe it's kwin's problem then?
Comment 16 ealexp 2011-08-03 12:13:14 UTC
Yes, it is related to Task Manager, not to kwin. I was talking about the bug report which wasn't about the case when a window is showed as "active" when it isn't.
Comment 17 S. Christian Collins 2011-08-03 15:36:33 UTC
Bug 279080 may be related to this bug, especially since they both seem to have started happening with the KDE 4.7 series, and both involve improper reporting of the actual window state.
Comment 18 ealexp 2011-08-04 12:56:17 UTC
(Also, I attached the screenshots that I talked about in another bug, sorry. They are here : https://bugs.kde.org/show_bug.cgi?id=278724)
Comment 19 Christoph Feck 2011-08-05 16:26:11 UTC
*** Bug 279328 has been marked as a duplicate of this bug. ***
Comment 20 Christoph Feck 2011-08-05 16:27:08 UTC
*** Bug 279080 has been marked as a duplicate of this bug. ***
Comment 21 Hussam Al-Tayeb 2011-09-06 20:14:42 UTC
I installed kdelibs from git 4.7 branch over my current kde 4.7 release. I don't see this bug happening anymore. 
I haven't tested much and it's only been 2 hours since I did that but I'm being optimistic :)
Comment 22 Hussam Al-Tayeb 2011-09-07 00:08:48 UTC
I spoke too soon.
It just happened again.
I'm not sure of the correct terminology in English but it seems to be "painting issue".
Comment 23 Nikola Schnelle 2011-09-12 21:10:45 UTC
*** This bug has been confirmed by popular vote. ***
Comment 24 Jean-Philippe Fleury 2011-10-08 14:33:43 UTC
I have this bug with KDE 4.7.1. My settings are:

Force row settings: no
Show tooltips: no
Highlight windows: no
Maximum rows: 2
Grouping: None
Sorting: Manually
Only show tasks from the current screen: no
Only show tasks from the current desktop: yes
Only show tasks from the current activity: yes
Only show tasks that are minimized: no

As mentioned on comment 1, the bug can be reproduced by clicking on an item on the task manager, then rapidly move the mouse cursor out of this item.
Comment 25 Silver Salonen 2011-10-09 10:54:13 UTC
Still happens in 4.7.2. I've found one action that always makes that highlighted button go away: I have one non-hidden panel at the bottom of the screen with Task Manager and another auto-hidden vertical panel for app launchers at the left of the screen, so whenever this non-responsive button sticks on the Task Manager, I just go to the left of the screen and once the other panel is shown, the sticky button disappears.
Comment 26 Silver Salonen 2011-10-23 12:23:47 UTC
This bug seems to be a duplicate of bug 275469 (which seems to be more actively investigated).
Comment 27 Marcus 2011-12-03 18:11:36 UTC
*** Bug 288116 has been marked as a duplicate of this bug. ***
Comment 28 Marcus 2011-12-03 18:24:37 UTC
The bug can be reproduced by switching fast between two items on
the task manager. The locked button can be unlocked by minimizing and restoring another application and clicking on the locked button again
Comment 29 Marcus 2011-12-03 18:35:25 UTC
Also happens with smooth-tasks, icon-tasks and fancy-tasks plasmoids
Comment 30 Silver Salonen 2012-01-04 19:59:49 UTC
It's been happening also throughout 4.8 pre-releases (currently I'm on 4.8 RC2, openSUSE packages). It's really annoying thing. Is the bug related to the phantom entries that sometimes stick on task managers?
Comment 31 Hussam Al-Tayeb 2012-01-04 20:55:55 UTC
(In reply to comment #30)
> It's been happening also throughout 4.8 pre-releases (currently I'm on 4.8 RC2,
> openSUSE packages). It's really annoying thing. Is the bug related to the
> phantom entries that sometimes stick on task managers?

I don't think so. the Qt patch in bug 275469 fixes that but but doesn't fix this one.
Comment 32 Nikola Schnelle 2012-01-07 19:24:39 UTC
From comment 1: "Now 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"

This easily reproduces the bug. 

Video: http://www.youtube.com/watch?v=JhPIQJm4Kl0&feature=youtu.be
Comment 33 Maxim Levitsky 2012-02-20 13:31:42 UTC
Happens here (kde 4.8 from ubuntu 12.04), and its 100% reproducible.
Comment 34 Nikola Schnelle 2012-02-22 16:42:12 UTC
This is Qt bug and it is now fixed.

Patches: https://bugs.kde.org/show_bug.cgi?id=275469#c173 (comment #173)

There is ppa with patched qt for Kubuntu users here: https://launchpad.net/~hrvojes/+archive/qt
Comment 35 Hussam Al-Tayeb 2012-02-24 11:45:06 UTC
(In reply to comment #34)
> This is Qt bug and it is now fixed.
> 
> Patches: https://bugs.kde.org/show_bug.cgi?id=275469#c173 (comment #173)
> 
> There is ppa with patched qt for Kubuntu users here:
> https://launchpad.net/~hrvojes/+archive/qt

I still see this 'with the patches'..just very rarely now and only with non-Qt applications.
Comment 36 dE 2012-03-01 14:48:52 UTC
Yet another annoying KDE bug. :( :x
Comment 37 dE 2012-03-03 06:08:17 UTC
I think the imporance should be changed.

This's a bug by which a lot of people will be affected -- the taskbar is used by virtually everyone.
Comment 38 Silver Salonen 2012-04-12 10:42:22 UTC
With Qt 4.8.1 installed the issue seems to be gone for good! :)
Comment 39 dE 2012-04-12 13:46:47 UTC
(In reply to comment #38)
> With Qt 4.8.1 installed the issue seems to be gone for good! :)

And KDE 4.7?
Comment 40 Silver Salonen 2012-04-12 13:49:21 UTC
I don't know, I use KDE 4.8.2 and Qt 4.8.1 (with KDE 4.8.1 and Qt 4.8.0 the bug was still present).
Comment 41 Hussam Al-Tayeb 2012-04-12 13:53:58 UTC
(In reply to comment #39)
> (In reply to comment #38)
> > With Qt 4.8.1 installed the issue seems to be gone for good! :)
> 
> And KDE 4.7?

if you are using Qt 4.8.1, you should be fine even with kde 4.7
Comment 42 Pablo Duboue 2012-05-18 06:09:20 UTC
If you go to the task manager settings and change the filters to "only show tasks for the current screen" and "force row settings" (with 2 rows) and then back to "normal", it will reset its state to correct behavior for a period of time.
Comment 43 Pablo Duboue 2012-05-18 06:12:31 UTC
(In reply to comment #42)
> If you go to the task manager settings and change the filters to "only show
> tasks for the current screen" and "force row settings" (with 2 rows) and
> then back to "normal", it will reset its state to correct behavior for a
> period of time.

Really sorry. That comment was for a different bug report. Please disregard (and delete it if that's possible).
Comment 44 Paul Elliott 2012-05-27 03:37:53 UTC
When My task manager sticks, it is much worse. All mouse clicks are ignored. Key board  does not work. Ctrl-Alt-F1 does not work. The only way I can get out of the situation, is login via ssh from another computer, and do a service kdm restart! Or sometimes shutdown -r now.
Comment 45 dE 2012-05-28 06:36:10 UTC
This sounds like an X problem.

Can you please post output of xorg logs?
Comment 46 Myriam Schweingruber 2012-05-28 10:06:09 UTC
Setting status correctly.
Comment 47 S. Christian Collins 2012-05-31 00:50:42 UTC
The bug as I originally reported it has been resolved with a Qt update as mentioned in comment #34.  Paul Elliot, your report in comment 44, which sounds more like a system freeze, is really a seperate issue that should be filed as a separate bug.
Comment 48 dE 2012-06-18 17:50:02 UTC
This problem is still reproducible with 4.8.3 and QT 4.8.1, mostly with GTK apps.
Comment 49 Hussam Al-Tayeb 2012-06-18 17:59:12 UTC
meh, I can reproduce it now on Qt 4.8.2 :( 
with firefox..
Comment 50 Henrik Pauli 2012-09-09 10:15:13 UTC
I still see this happen in 4.9.
Comment 51 Hussam Al-Tayeb 2012-09-09 10:32:43 UTC
Requesting a reopen. this still happens with qt 4.8.2 and KDE 4.9
Comment 52 Myriam Schweingruber 2012-09-10 12:02:33 UTC
Folks, please calm down. I tried repeatedly with KDE 4.9.0, Qt 4.8.2 and was never able to reproduce this report, using several non-KDE applications.

For all those experiencing this bug with KDE 4.9.0 or later: could you please test with a new user (e.g a user with no previous $HOME/.kde/ or $HOME/.kde4/ folder) and try again?
Comment 53 dE 2012-09-10 14:58:29 UTC
To those who're facing this problem: have you enabled composting?
Comment 54 Hussam Al-Tayeb 2012-09-10 15:56:46 UTC
new profile. I start a new profile every major KDE release.
compositing is enabled and this only happens with non-Qt applications.
Comment 55 Marcus 2012-09-10 16:36:18 UTC
In fact I have only seen this with Firefox/Thunderbird. Btw. other panels like LXpanel have similar problems:

http://sourceforge.net/tracker/?func=detail&aid=3565712&group_id=180858&atid=894869

So I guess it is somewhat xulrunner related.
Comment 56 Henrik Pauli 2012-09-11 22:00:28 UTC
I have recently reinstalled my machine, so I guess the user is quite fresh.  I just experienced this between two Qt-based applications, namely Gwenview and Skype.

I have also found earlier today that if you manage to drag the button (even with manual reordering disabled), it'll cause some weirdness with the pressed state:
• Have something focused, doesn't matter what.
• Go to another task bar button and click-drag it, just enough that the drag mode turns on
• Drop it (on itself, on another button, doesn't seem to matter).  It'll remain pressed.

It does look weird, and I'm not sure if it's actually related to this issue.  With all the highlighting (#275835) and this issue going on, I'm not really sure which one is still in effect... might be getting the "stuck" effect because we don't know what we're clicking on...
Comment 57 dE 2013-05-07 17:20:42 UTC
Oh, and this still persists with 4.10.2.