GNOME Bugzilla – Bug 400167
KDE apps "alert" ("blinking" on panel) when switching workspaces in metacity
Last modified: 2007-06-18 17:01:16 UTC
Please describe the problem: When I switch to a workspace where a KDE application is placed, but doesn't get focus upon switching (due to some other application getting focus instead), the KDE app appears as if it requests attention to an event and thus "blinks" on the gnome-panel. This happens to ALL KDE windows that may live in that workspace, not currently in focus. Steps to reproduce: 1. Open a KDE application window in your current workspace 2. open another application window (can be another KDE or Gnome, doesn't matter) and make sure the second window has focus (leaving the first KDE window un-focused) 3. Switch to another workspace and then switch back to the first workspace Actual results: Upon switching to the workspace with the unfocused KDE window, its icon-bar in gnome-panel is blinking as if an event has occurred Expected results: blinking should happen Does this happen every time? yes Other information: I think it's a metacity problem/incompatibility(?) (and not the gnome-panel's for instance), because this doesn't happen when compiz is used as the window manager.
compiz has a bug where it doesn't notify anyone when focus-stealing-prevention kicks in, as discussed recently on its mailing list. So compiz isn't really a relevant comparison. kwin would be (and yes, you can use kwin under gnome; it works great) That said, this does sound like a strange bug somewhere. I thought we had this filed somewhere else, but I can't find it at the moment. It would be nice to have a verbose debugging log to see why the demands_attention setting gets triggered for these windows.
OK, I've just tried kwin and it doesn't exhibit the same behaviour as metacity. so, how do I generate this debugging log?
1. Reduce your desktop to as few windows as possible to reproduce the bug 2. Run METACITY_VERBOSE=1 METACITY_USE_LOGFILE=1 metacity --replace 3. On stdout metacity will print the name of the logfile 4. Reproduce the bug as quickly as possible 5. Kill the metacity you started above to stop the logfile from growing any longer 6. Attach the logfile here
Created attachment 81117 [details] metacity verbose output This is using Metacity 2.17.5
Created attachment 81606 [details] Result of METACITY_VERBOSE=1 METACITY_USE_LOGFILE=1 metacity --replace I do have the same bug. I've run "METACITY_VERBOSE=1 METACITY_USE_LOGFILE=1 metacity --replace" with 2 windows: gnome-terminal and KPDF. Just after metacity has replaced the old one, KPDF blinks, without even swithing workspace. I kill the new metacity (ctrl+c) and end up with this log file.
Created attachment 81607 [details] Result of "METACITY_VERBOSE=1 METACITY_USE_LOGFILE=1 metacity --replace" with switching workspace I ran "METACITY_VERBOSE=1 METACITY_USE_LOGFILE=1 metacity --replace" with Firefox, gnome-terminal and KPDF. KPDF was blinking, so I selected it to stop it from blinking. I then switched workspace and came back to the original one. KPDF was again blinking. I killed the new metacity (ctrl+c) and here is the log file. Thanx
Sorry I forgot. I'm using Ubuntu Edgy Eft 6.10 with metacity 2.16.3 See Ubuntu's bug report #78511 (https://launchpad.net/ubuntu/+source/libwnck/+bug/78511)
*** Bug 398540 has been marked as a duplicate of this bug. ***
It seems that kwin does a similar thing. it doesn't cause this "notification alert" when you switch between workspaces, but it does it when you flick across application via the gnome-panel window list applet. Could it be that this is a window list applet bug and not a metacity specific one?
Isn't anyone working on this? It's easily reproducible. It happens to any Fedora 6 installation I've seen, either that's 386 or x86_64. And I've seen this happening in an Ubuntu one as well
I just found out that the "notification"/"alert" doesn't happens if there is no application on top of the KDE one. In other words if the windows are side-by-side and not overlapping at all, switching workspaces doesn't cause a false-alert! that should give you an extra clue of what may cause this. thanks
i.nousias: No, sorry. Finishing my dissertation and jobsearching basically removed me from metacity development for about 6 months (and is expected to be problematic for another month or so); I've only had time to comment on some bugs here and there to gather the appropriate info or drop hints for other people who may want to work on fixing things. Hopefully I should be able to start attacking my long backlog in about a month, though I have no idea how much time moving is going to suck out of my schedule...
i can confirm this bug with amarok and ktorrent. running Ubuntu Edgy Eft 6.10 with metacity 2.16.3 ( also happend in Dapper)
This bug also occurs when you click the desktop applet (to minimize all windows) and then click it again immediately (to re-open all the windows that were just minimized). The bar does not flash until the second click.
Using now Fedora 7 with metacity 2.18.0 and the bug is still present. Any updates on this?
Just to let you know that this bug is also present in metacity 2.19.8.
*** Bug 445835 has been marked as a duplicate of this bug. ***
I hadn't previously known about bug 400167, but during investigation of bug 445835 (a duplicate of this one) I contacted the kwin people, who said that they think it's a metacity problem: http://lists.kde.org/?l=kwin&m=118147703932025&w=2 I think the next thing to do is to find out what is actually sending the activation message.
After a good deal of code-spelunking, I find two problems. A) The minor problem: KCalc sends a PropertyNotify event for the property _NET_STARTUP_ID to the root window when the workspace changes. gnome-calculator and the small number of other GNOME programs I've tested it with do not. The timestamp on the event appears to be rather in the past. We should figure out whether it's appropriate to send _NET_STARTUP_ID in these circumstances, and with these timestamps, and ask KDE to fix their libraries if not. B) The major problem: When a window updates its _NET_STARTUP_ID, we activate it. The spec says: If a new value for the property is set, the window manager should update the window's status accordingly (update its virtual desktop, etc.). But does "a new value" mean a different value from before, or any attempt to set the value? If the former, we're not behaving according to the spec. I haven't yet checked what kwin does. For the curious, the call stack goes: 1. KCalc sends us a PropertyNotify event for the property _NET_STARTUP_ID every time the workspace changes; the event apparently has the timestamp of the original startup (but I'm not certain of this). The event is handled by event_callback(). 2. This passes the event to meta_window_property_notify()... 3. ...which is a wrapper for process_property_notify()... 4. ...which calls meta_window_reload_property()... 5. ...which is a wrapper for meta_window_reload_properties()... 6. ...which is a wrapper for meta_window_reload_properties_from_xwindow()... 7. ...which eventually calls reload_prop_value()... 8. ...which demultiplexes (since the event is _NET_STARTUP_ID) to reload_net_startup_id()... 9. ...which calls meta_window_activate_with_workspace()... 10. ...which is a wrapper for window_activate()... 11. ...which sees that the activation attempt is older than the latest timestamp, and ignores it except for setting the attention hint on the window.
Good detective work, Thomas. :-) If you follow the thread you linked to in the latest duplicate, you'll see the following response from Lubos: http://lists.kde.org/?l=kwin&m=118150672531490&w=2 Looks like you confirmed his suspicion. :-) I really think it's kind of buggy of KDE apps to reset that property on every map, but I agree with Lubos that it's buggy of us to respond to such property changes for already used startup ids. So, the problem seems to be the following code in reload_net_startup_id: meta_screen_apply_startup_properties (window->screen, window); if (window->initial_timestamp_set) timestamp = window->initial_timestamp; if (window->initial_workspace_set) workspace = meta_screen_get_workspace_by_index (window->screen, window->initial_workspace); meta_window_activate_with_workspace (window, timestamp, workspace); meta_screen_apply_startup_properties will exit early for startup_ids that aren't active (i.e. already used). However, we run the few lines following that unconditionally. We should either make meta_screen_apply_startup_properties return a boolean and run the following lines conditionally, or move those lines into the end of that function so that they can be skipped as appropriate.
*** Bug 370327 has been marked as a duplicate of this bug. ***
Thomas, did you want to create the patch for this one, or did you want me to?
I am actually in the middle of fixing it; Father's Day stuff intervened. I think I'll make a release when it's done (sometime this evening).
Cool. We should also make sure it gets fixed in the gnome-2-18 branch. :-)
Okay, checked in in trunk and gnome-2-18. Hurrah!
Awesome, thanks Thomas! Could you attach the patch to bugzilla? I can get it from subversion to look over it, but attaching it here makes it easier for distros that want to backport the patch (and I believe there will be multiple distros wanting this one). Attaching it also makes it more convenient for others who are reading over the history of bugs to check out the changes.
Created attachment 90201 [details] [review] Stop KDE apps blinking on the panel when switching workspaces Here we go.
I appear to have opened this again accidentally. Closing. Sorry for the spam.