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.
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!!!
(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!
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.
This happens to me too.
*** Bug 278881 has been marked as a duplicate of this bug. ***
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"?
Yes, I do use the "only show tasks from current desktop" setting.
These are my settings: http://img508.imageshack.us/img508/893/screenshot6fy.png
I've turned off all the "only" settings, because I use only one desktop and one activity.
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
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.
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.
(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?
That's it... but it doesn't mention the case when a window is showed as "active" when it isn't.
(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?
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.
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.
(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)
*** Bug 279328 has been marked as a duplicate of this bug. ***
*** Bug 279080 has been marked as a duplicate of this bug. ***
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 :)
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".
*** This bug has been confirmed by popular vote. ***
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.
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.
This bug seems to be a duplicate of bug 275469 (which seems to be more actively investigated).
*** Bug 288116 has been marked as a duplicate of this bug. ***
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
Also happens with smooth-tasks, icon-tasks and fancy-tasks plasmoids
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?
(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.
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
Happens here (kde 4.8 from ubuntu 12.04), and its 100% reproducible.
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
(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.
Yet another annoying KDE bug. :( :x
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.
With Qt 4.8.1 installed the issue seems to be gone for good! :)
(In reply to comment #38) > With Qt 4.8.1 installed the issue seems to be gone for good! :) And KDE 4.7?
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).
(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
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.
(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).
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.
This sounds like an X problem. Can you please post output of xorg logs?
Setting status correctly.
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.
This problem is still reproducible with 4.8.3 and QT 4.8.1, mostly with GTK apps.
meh, I can reproduce it now on Qt 4.8.2 :( with firefox..
I still see this happen in 4.9.
Requesting a reopen. this still happens with qt 4.8.2 and KDE 4.9
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?
To those who're facing this problem: have you enabled composting?
new profile. I start a new profile every major KDE release. compositing is enabled and this only happens with non-Qt applications.
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.
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...
Oh, and this still persists with 4.10.2.