GNOME Bugzilla – Bug 657990
Apps disappear from the alt-tab switcher, seemingly randomly (since 3.1.5)
Last modified: 2011-09-05 21:31:21 UTC
With gnome-shell 3.1.4 and 3.1.90, apps frequently disappear from the alt-tab switcher. They're still running perfectly normally, and you can happily switch to them by other means (overview, for e.g.), but they don't appear in alt-tab at all. As I'm writing this in Firefox, if I hit alt-tab, Firefox does not show up in the list at all. Restarting Shell restores the lost app. I'm yet to figure out exactly what causes this, or whether it affects all apps or only a specific subset. It seems to affect Firefox the most, but then Firefox is probably my most-used app. Running F16.
Confirmed.
so, just in case it helps, I've noticed this. in the case where Firefox has disappeared from the switcher, follow these steps: * alt-tab to gnome-terminal * alt-tab to xchat * select Firefox window by clicking on it * hit alt-tab the alt-tab switcher will show xchat first in the list, and gnome-terminal second and highlighted. i.e., it thinks you just switched away from xchat.
I've audited a fair bit of code for reference-count issues, but coming up with nothing. What I really really could use is a somewhat reliable reproducer.
I really haven't noticed it be related to any particular operation on the desktop unfortunately, it seems to just...happen :/ it happens to me quite a *lot*, usually within an hour of starting a desktop session, but it doesn't seem to reliably happen after I do some particular thing, sadly.
yeah, I don't have a good reproducer, but since the least couple of days (I would say less then a week), I end up in this situation in 100% cases just after of working or so. And yes restarting gnome-shell helps (thanks!).
I'm pretty sure this showed up in gnome-shell-3.1.4-2.gite7b9933.fc16 - I first reported it on 08-22, which is shortly after that was built. So it was between 3.1.4 and that git snapshot.
Ok, so here's what I have so far. Alt-TAB gets its data from shell_window_tracker_get_running_apps(). This, in turn is based on tracking the state of various apps. The "running" state is presently defined as "has open windows". When I lose an app, and do: Shell.AppSystem.get_default().lookup_app('mozilla-firefox.desktop').get_windows() I indeed see that there are no windows associated. Why are there no windows for the app? There's two code paths that remove them: shell-window-tracker.c:disassociate_window() shell-app.c:shell_app_on_unmanaged() The former only happens when a window leaves a workspace. I don't switch workspaces personally, so that's probably not it. I think this may have something to do with the MetaWindow::unmanaged chain...possibly something like us not handling transient/uninteresting windows being unmanaged correctly. It may also just be memory corruption (I haven't actually tried running in valgrind) but that seems unlikely.
yeah, I do not use workspaces either, so it's not likely to be the workspace thing.
Created attachment 195541 [details] [review] instrumentation
Ok, so I think one big problem here is if the app state changes - such as when a tar wrapper like yum/dpkg/emerge rip away .desktop files, we don't know what's changed. So we reread the whole thing currently, and are basically left with a merge problem. In the pre-gnome-menus-rework code, we identified apps by string ID mainly. However in the new one, we centralize more on the GMenuTreeEntry. The problem is that we dump the old GMenuTreeEntry's after reloading. I think probably the best fix is for *running* apps, return the old version as long as they exist. This means you won't see description/icon/whatever updates until you close the app, but this seems right to me.
what would be causing apps' states to change so often, though? is there anything 'special' about firefox in this regard which might explain why it seems so subject to this bug?
This is pretty easy to reproduce now that I've diagnosed it: 1) Have an open firefox window 2) (as root) mv /usr/share/applications/palimpsest{2,}.desktop 3) Go back to firefox and open a new window 4) Close that new window The original firefox window isn't counted as running anymore because the new firefox.desktop data we read overrode the old one.
Created attachment 195580 [details] [review] apps: Ensure running apps override new .desktop file data This patch fixes the "apps vanish from alt-TAB bug". If a "package system" rips away and possibly replaces .desktop files at some random time, we have historically used inotify to detect this and reread state (in a racy way, but...). In GNOME 2, this was generally not too problematic because the menu widget was totally separate from the list of windows - and the data they operate on was disjoint as well. In GNOME 3 we unify these, and this creates architectural problems because the windows are tied to the app. What this patch tries to do is, when rereading the application state, if we have a running application, we keep that app around instead of making a new instance. This ensures we preserve any state such as the set of open windows. This requires moving the running state into ShellAppSystem. Adjust callers as necessary, and while we're at it drop the unused "contexts" stuff. This is just a somewhat quick band-aid; a REAL fix would require us having low-level control over application installation. As long as we're on top of random broken tar+wget wrappers, it will be gross. A slight future improvement to this patch would add an explicit "merge" between the old and new data. I think probably we always keep around the ShellApp corresponding to a given ID, but replace its GMenuTreeEntry.
Review of attachment 195580 [details] [review]: this will need some more finessing post-3.2... eg, it seems pretty weird that shell-window-tracker still keeps track of autostart-related stuff, but not running apps. ::: js/ui/panel.js @@ -295,2 +296,2 @@ tracker.connect('notify::focus-app', Lang.bind(this, this._sync)); - tracker.connect('app-state-changed', Lang.bind(this, this._onAppStateChanged)); + appSys.connect('app-state-changed', Lang.bind(this, this._onAppStateChanged)); should also fix: _onAppStateChanged: function(tracker, app) { (it doesn't actually use the "tracker" param, but someone might try in the future) ::: src/Makefile.am @@ +127,3 @@ $(shell_public_headers_h) \ shell-app-private.h \ + shell-system-private.h \ shell-APP-system-private.h ::: src/shell-app-system.c @@ +266,3 @@ + /* Here we check to see whether the app is still running; if so, we + * keep the old data around. do we need to do this for settings entries as well? @@ +517,3 @@ { + /* If we looked up directly in ->entry_to_app, we'd lose the + * override of running apps. Thus, indirect through the id. seems like entry_to_app is now just there to trick people into looking things up the wrong way. would it be better to change it to desktop_id_to_app?
(In reply to comment #14) > > this will need some more finessing post-3.2... eg, it seems pretty weird that > shell-window-tracker still keeps track of autostart-related stuff, but not > running apps. It does the mapping still, but yes; suggestions welcome. > ::: src/shell-app-system.c > @@ +266,3 @@ > > + /* Here we check to see whether the app is still running; if so, we > + * keep the old data around. > > do we need to do this for settings entries as well? No, a setting can never be running - only gnome-control-center can be. It's really tempting to move all of the control-center communication glue into a gnomecc-client.h class, right now we have bits in ShellAppSystem, Util.spawn in other places. > seems like entry_to_app is now just there to trick people into looking things > up the wrong way. would it be better to change it to desktop_id_to_app? Yes...I'll keep that in mind for a future cleanup, but I don't want to obscure the core changes here too much in this patch.
Attachment 195580 [details] pushed as 0af1082 - apps: Ensure running apps override new .desktop file data