GNOME Bugzilla – Bug 700356
Alt-tab doesn't switch back to previous window between workspaces
Last modified: 2013-05-15 14:33:39 UTC
This issue can be reproduced by doing the following: • Workspace 1: terminal window A • Workspace 2: firefox & terminal window B • Hitting alt-tab from terminal A takes you to firefox • Hitting alt-tab again then takes you to terminal B, where you would normally expect it to go back to the last window that had focus. This line of code is responsible for jumping to the 1st element in the app's window list in this scenario. • https://git.gnome.org/browse/gnome-shell/tree/js/ui/altTab.js#n132 A potential solution could be to sort the cachedWindows list by last time each window was activated.
Ugh, that's a regression from commit 2499f2ed8098110845 ...
Created attachment 244273 [details] [review] altTab: Always activate MRU window when activating an app Commit 2499f2ed80 went back to using shell_app_activate() for selecting an app, which favors windows on the current workspace; this is the behavior we want for instance when activating a launcher, but it's wrong for the alt-tab list - explicitly request the first (e.g. MRU) window in that case.
Review of attachment 244273 [details] [review]: Looks fine
Attachment 244273 [details] pushed as 7833e21 - altTab: Always activate MRU window when activating an app
Review of attachment 244273 [details] [review]: Couldn't you merge this with the activateWindow path? What if you select an app that has no windows on the current workspace?
(In reply to comment #5) > Couldn't you merge this with the activateWindow path? No. The design asks for *all* window of an application to be raised when activating an app, but only a particular window when selecting a window. > What if you select an app that has no windows on the current workspace? Nothing in particular - the most-recently-used window is activated, independent from the workspace it's on. We just got rid of special-casing workspaces, let's not bring it back ...
(In reply to comment #6) > Nothing in particular - the most-recently-used window is activated, independent > from the workspace it's on. So we won't switch to the workspace? That seems a bit broken to me.
(In reply to comment #7) > So we won't switch to the workspace? That seems a bit broken to me. It's not broken, activating a window involves a workspace switch if necessary.