Bug 275835

Confirmed, this happens on my installation of kde too

This still persists in KDE 4.7rc2.

Using qtcurve widget theme, Oxygen icons, qtcurve window decorations, and produkt desktop theme.

It seems to happen more often with things that you have minimized to the systray and when you restore them the window in the taskbar flashes 3 times like it demands attention, and then has a colored border around it. This sometimes goes away when you switch from the application (with alt-tab or such) to another one. but reappears when you hover the window in the taskbar. I can make a video if that helps..

happens here as well.
Using oxygen desktop theme, plastic window decoration, qtcurve widget style, oxygen icons. 
Jonas Nyrén alerady described pretty much what I see. Also, if a window actually needs attention (like instant messaging), the state often gets "stuck" to it.

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

I too have this bug with KDE 4.7.1, not only with default theme, but also with third party desktop themes.

May be related to bug 274020

This does not only happen with newly started applications when you steal their focus, it happens seemingly randomly with applications that have been running for some time.

If this behavior starts and you manage to remove the outline by switching to another task - as soon as your mouse hovers the icon in the taskbar the outline comes back and stays there again.

Already 4 months and no interest from any developer on this bug, it's a sad state of KDE really.

still persists in KDE 4.7.2

I just updated from kubuntu 11.04 to 11.10 and now I am getting this bug.  It only happens with certain applications, though.
ktorrent - the taskbar entry is always highlited
chrome & dolphin - the taskbar entry gets highlited whenever i hover over it

still persists in KDE 4.7.4

Steps to reproduce:
1) Run application like ktorrent or kopete and minimize it to tray.
2) Run another application and make it active.
3) Click on [1] app icon on tray to restore it.
4) Now [1] keeping "demand attention" look.
Using KDE-4.7.3 on gentoo x86-64.

I can reproduce the bug using LT's steps and Amarok as application [1] on KDE 4.7.4 on Kubuntu x86-64, too.

Any updates? Does this still persist in 4.8.0?

Hello, I am the bugreporter of an identical bugreport. Alexander Kiselyov told me about other bugreports identical as mine, so I create this post to link all of them so someone of the admins can merge them.

https://bugs.kde.org/show_bug.cgi?id=286948
https://bugs.kde.org/show_bug.cgi?id=275835
https://bugs.kde.org/show_bug.cgi?id=274020

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

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

Any news?

i updated both of my computers from kubuntu 11.10 to 12.04, and i'm not getting this issue any more.  kinfocenter reports KDE version 4.8.2.

I can still reproduce the bug with the steps from comment 10 on Kubuntu 12.04 with KDE 4.8.2.

Created attachment 70798 [details]
application highlight in taskbar

(In reply to comment #18)
> I can still reproduce the bug with the steps from comment 10 on Kubuntu
> 12.04 with KDE 4.8.2.

It reproduces after dialog windows in krusader too. Dialog popup (in example: confirm to overwrite files), i close dialog, app still highlight in taskbar.

Bug exists on KDE4.8.2, provided with Ubuntu 12.04. 

It's brutal on certain themes where the task-bar icon glows white instead of black.  At any point in time I have ~20 items in the task bar, a quarter of which demand attention, so it looks like a checkerboard. 

Once thing I noticed, if you bring an app to the foreground, the taskbar icon un-highlights, then you minimize the app, then you mouse-over the task bar icon, as the mouse leaves the task bar icon, it suddenly highlights again.  

Is there a way to easily disable the app-attention highlight in the task bar completely?  I know it sounds like a simple bug, but it's incredibly frustrating as it causes users to miss attention-required actions and event reminders.

r,
-edfardos

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.

Confirmed workaround, 

[x]  "Only show tasks from the current desktop"
[apply]
[  ] "Only show tasks from the current desktop"  (uncheck)
[apply]

restores normal attention behavior in task bar for a while...

I see this bug in Kubuntu 12.04 (looks like KDE version 4.8.2a-0ubuntu4).

I found an easier workaround than the checkbox setting above, although it's not perfect, and it requires that you have "Taskbar Thumbnails" enabled in desktop effects:

Hover over the taskbar entry until the window thumbnail shows up, and click on the thumbnail. The highlight will go away when you switch back to another window, but when the now-fixed window is active, it will have the "Needs Attention" graphic in the taskbar.

But at least it's not there when you are in a different window...

Guys, I can confirm again this bug in KDE 4.8.4.
Developers:
what about taking it more seriously? See the vote list, it is more than confirmed!

i'd like to help debug and diagnose this properly too, but yet to see reliable recipe to reproduce this phenomenon.  (all my previous attempts have failed).

My take so far is that it only happens with gnome apps that have
requested attention. The task bar doesn't reset itself properly.

On 6/26/12, Rex Dieter <rdieter@math.unl.edu> wrote:
> https://bugs.kde.org/show_bug.cgi?id=275835
>
> --- Comment #26 from Rex Dieter <rdieter@math.unl.edu> ---
> i'd like to help debug and diagnose this properly too, but yet to see
> reliable
> recipe to reproduce this phenomenon.  (all my previous attempts have
> failed).
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
>

I see this most often with Amarok and Eclipse. Amarok usually after restoring from the system tray, Eclipse usually at startup. I have not seen this as much (or perhaps at all) during the past week or so, and cannot seem to reproduce while actively trying right now.

Ubuntu package kde-runtime is at 4.8.3.

I can still reliably reproduce it with the steps from comment 10 on Kubuntu 12.04 with KDE 4.8.4, using e.g. KTorrent and Dolphin. Thus it doesn't only happen with Gnome apps.

Yes, the steps in comment 10 worked to reproduce in 4.8.3 on Kubuntu.

Note that when you switch back to [1], you need to CLICK on it. Using Alt+Tab will not show the needs-attention highlight, but even if you Alt+Tab to it, then away, then click on it, it will show like it needs attention.

For me its usually eclipse or kopete that "causes" the problem

I guess I admit defeat then, no amount of filddling with either eclipse, amarok, ktorrent, or kopete allowed me to reproduce this myself (on either my fedora 16/x86_64 box with kde-4.8.4 or fedora 17/x86_64 one with kde-4.8.90 currently)

I can confirm this problem, but unfortunately I don't know a way to reproduce it. Temporary (!) workaround from comment #23 works. 

It is quite annoying  when windows are highlighted (especially kopete windows..).

I too have been having this for a looong time now, very often with assorted Krusader windows. I'm running 4.8.3 on Gentoo.

Just now I had it again (which made me reply here finally). I was switching between two windows, from KMyMoney to LibreOffice and Krusader. Whenever I clicked on KMyMoney to bring it to the foreground, its taskbar entry would remain highlighted (non-flashing) in its *selected* state. If I clicked on the LO item and then switched back to KMM with Alt+Tab, the item didn't get highlighted.

just add that I have it on 4.8.95

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

should be fixed in gd3b3cd4.

http://quickgit.kde.org/index.php?p=kde-workspace.git&a=commit&h=d3b3cd48f7b32ef891a85e5321b3c61469ae1df3

Hallelujah

I am still have problems with patch from Comment 37.
Seamonkey started on background of other applications with status 'asking for attention' but this status stays after switching to semonkey window and disappears only after switching to other desktop and back.

Note that I have taskbar option to show windows only from current desktop.
Konqueror was as background window but when certificate confirmation window appeared it was needed attention but after i switched to konqueror window this state remained.

Stupid question. Is there any way we can apply the fix or do we need to wait for it to be released. If we need to wait, how can we tell which release it will be included in? I am using KDE 4.9.0 and I'm still having this bug.

As I set above, it should come with 4.9.1.

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

I applied the patch to kde 4.8.4, and still get the same behavior (recompiled libtaskmanager.so).  The easiest way for me to replicate it is to simply open kopete.  It demands attention when it's maximized.   click on it, and the task manager un-highlights as you'd expect, but then go back and mouse-over the taskmanager icon for kopete, and it highlights as the mouse leaves the icon.

Was there another code change that I missed?


~/dev/kde-workspace_4.8.4a/kde-workspace-4.8.4a/libs/taskmanager:

void Task::setActive(bool a)
{
    d->active = a;
//edfardos
//  emit changed(StateChanged);

    TaskChanges changes = StateChanged;

    if (demandsAttention() != d->demandedAttention) {
        d->demandedAttention = !d->demandedAttention;
        changes |= AttentionChanged;
    }

    emit changed(changes);
//end edfardos


compiled into /usr/lib/libtaskmanager.so -> /usr/lib/libtaskmanager.so.4.8.0

what'd I miss?

I think I can confirm the patch fixes one manifestation of the issue (I don't see it happen with chromium or thunderbird or other traditional apps).

However as  Jonas Nyrén said, "It seems to happen more often with things that you have minimized to the systray", specifically kopete.  If I never maximize kopete, the but is completely fixed imho.  Maybe this manifestation is a kopete bug.  But it's fixed otherwise. 

thanks!
-edfardos

I'm afraid I experience this one in 4.9 still...

(In reply to comment #46)
> I'm afraid I experience this one in 4.9 still...

As you can see it was fixed in 4.9.1 which is ahead of 4.9.0

I still get it in 4.9.1 too. I have three tasks highlighted at the moment, one of which is a KDE app (Konsole).

Can somebody else with KDE 4.9.1 reproduce this? Please also test with a new user.

In KDE 4.9.1 I have the same problems as in Comment 39.

And for new user problem still appears (when option show windows only from current desktop selected).

for me it seems resolved, except for gKrellm which demands attention but then when clicked or restarted it is fine (which would might be considered normal)

KDE 4.9.1
I updated today, and at the moment I am having this bug with Firefox.

happens infrequently  now but seems (iirc) to be non-KDE apps like Opera and even then infrequent and closing and restarting the app clears it.

This still happens to me with speedcrunch.

could you use xprop and make sure that it isn't actually an application bug (for example if it forgets to clear its own demands attention flag)?

anywho, I've heard that the task manager plasmoid is going to be replaced in the near future with a QML-based one.

(In reply to comment #56)
> make sure that it isn't actually an application bug
It is not an application bug at all, since I am having this bug with a discrete amount of applications like:
- Amarok
- Pidgin
- Firefox
- others that I forgot at the moment

(In reply to comment #57)
> (In reply to comment #56)
> > make sure that it isn't actually an application bug
> It is not an application bug at all, since I am having this bug with a
> discrete amount of applications like:
> […]

So?

Also make sure you are actually using an up to date version.

But it is fixed for me now, so I'm unsubscribing.

(In reply to comment #58)
> (In reply to comment #57)
> > (In reply to comment #56)
> > > make sure that it isn't actually an application bug
> > It is not an application bug at all, since I am having this bug with a
> > discrete amount of applications like:
> > […]
> 
> So?
> 
> Also make sure you are actually using an up to date version.
> 
> But it is fixed for me now, so I'm unsubscribing.

They are updated to lastest version

okay, I manage to reproduce it again, unfortunately, I'll see if I can look into this again.

some more comments; one way to reproduce it is to use Juk, and just click its systray icon a lot of times. It happens very intermittently, which makes me suspect we're somehow losing some events or something.

I checked with xprop that the flag is not set for the window.

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

... and I can't reproduce at all when running tasks in plasmoidviewer, for some reason, makes it very hard to work on a fix.

Appends with Firefox when it starts in background in KDE 4.10.

I am having this trouble right now on Dolphin, KDE 4.9.5 + Fedora 18.
If I can do anything to retrieve useful infos, please let me know

Appends today with Kate, KDE 4.10 on Arch Linux. Still don't know why…

1.5 years and nothing.. unsubscribing.

Ok I found how to reproduce this bug:
– clic on an application icon to launch it
– open Yakuake (or maybe other apps?) before the app is launched
– when the app appear, there are a big chance that she "demand attention" forever

(In reply to comment #68)
> Ok I found how to reproduce this bug:
> – clic on an application icon to launch it
> – open Yakuake (or maybe other apps?) before the app is launched
> – when the app appear, there are a big chance that she "demand attention"
> forever

Interesting, I do use Yakuake every day (I have it on autostart)

I have it on autostart too. If it's not clear, what I mean by "open Yakuake" is "give focus on Yakuake window".

Confirming on KDE 4.10-1

Comfirming on 4.10.2

Confirming on 4.10.3. Maybe you can look at icon-tasks’ code because this plasmoid don’t have this bug.

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

This is fixed with new QML taskmanager in 4.11 :-)
(I've been using Eike's clone for a few weeks, didn't experience the issue neither once)

has it been merged?

(In reply to comment #76)
> has it been merged?
Yes :-)

in 4.11b1 there is intermittent occurrences of this (openSUSE 12.3 x64), sometimes no apps call for attention and infrequently 1 or 2

clicking on the app's task manager tab and the flashing/highlighting stops, pre-4.11b1 the app need to be restarted to fix the demand for attention

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

Please explain what you mean.

No applications are able to show that they are able to demand attention, or are some applications demanding attention when they shouldn't? Which applications?

(In reply to comment #80)
> Please explain what you mean.
> 
> No applications are able to show that they are able to demand attention, or
> are some applications demanding attention when they shouldn't? Which
> applications?

some apps demanding attention when they shouldn't, Konsole would be an example

this isn't every startup and sometimes different apps but always clicking on the app in the task manager turns off the highlight, previously I needed to restart the app to get rid of the highlighting

adding Eike.

fyi -just rebooted - gKrellm, Konsole and Konversation are calling for attention, clicking them in the task manager removes the highlighting

btw, is this when they are launched, and appear behind other windows? if so, that's expected behaviour, AFAIK.

(In reply to comment #84)
> btw, is this when they are launched, and appear behind other windows? if so,
> that's expected behaviour, AFAIK.

if true that would be unexpected expected behavior, why would a window call for attention just because it was behind an other window? when you have multiple apps run at startup there's always going to be apps below other apps (especially if they are set to open centered on the desktop). One of the apps calling (gKrellm) is never covered as it is forced to open on the side of the screen but has called for attention.

also the calls for attention are inconsistent - sometimes no apps call

>if true that would be unexpected expected behavior

See http://docs.kde.org/stable/en/kde-workspace/kcontrol/windowbehaviour/index.html

>Windows that are prevented from stealing focus are marked as demanding attention, which by default means their taskbar entry will be highlighted. This can be changed in the Notifications control module.

ok, please open a new bug if apps aren't set as demanding attention when they should.