GNOME Bugzilla – Bug 535887
Alt+Tab window switching sometimes starts from active window, and sometimes from next
Last modified: 2020-11-06 20:05:14 UTC
Please describe the problem: Fedora 9, Gnome 2.22, X.org 7.3 with the 'nv' X11 driver, compositing disabled. When pressing Alt+Tab (in fact I use <LWIN>+Tab which is Meta in my setup) sometimes window switching starts from next window (the expected behavior), and sometims from active window (so you have to press Meta+Tab, Tab to switch to next window). I can't find any conditions when this occurs: sometimes after login it works normally, sometimes it is broken. Steps to reproduce: 1. Log in and open a couple of different windows (say, firefox and a terminal). 2. Activate, say, firefox. 3. Press Alt+Tab and depress Tab but don't depress Alt Actual results: The window switch pane will appear. *Sometimes* the selected window on the pane will be (incorrectly) firefox, sometimes (correctly) the terminal. Expected results: Does this happen every time? Unfortunately, no, but pretty often. The bug sometimes appears or disappears by itself even during a single session. Running metacity --replace, then Ctrl+C almost always 'fixes' it. Other information: I tried to compile a debug version of metacity with debug tracing enabled. I tracked the bug up to the place where do_choose_window() calls meta_display_get_tab_next(). Here things get very complicated, and I don't know why meta_display_get_tab_next() sometimes returns the active window and sometimes the next window. Perhaps some uninitialized variable issue?
Here's a video of the bug, captured with xvidcap. http://cs.ozerki.net/zap/metacity-alttab-bug.mkv (~1.1Mb) In the meantime I have installed nvidia proprietary drivers and turned compositing on. However, the bug is still present, and I can now say that it appears from time to time even if you don't relogin, e.g. for some time it can work ok, then appears again for some time and so on.
I found something that could give a clue to the problem. I'm using multiple desktops (10 to be precise) using the Gnome's standard desktop switcher applet. Now when the bug described above appears I have observed that there's a window in the loop that belongs to a different desktop. That is, Alt+Tab is supposed to show only windows attached to current desktop, but sometimes a window from a different desktop sneaks in. In the movie above you can see the XChat application in the window list, although XChat was running (non-minimized) on desktop 9 while I was taking the screenshots on desktop 5. When it breaks like this, I can see that window in the list on any desktop. If I switch to the desktop where window is actually placed and press Alt+Tab, the bug disappears - that is, I can switch to another desktop and then Alt+Tab works normally. I don't know what causes the switcher to behave like that, but it's not related to XChat - I just got a situation where Firefox was visible in the window list on all desktops.
A long time have passed, and there's no feedback on this bug. I can't understand, I'm the only one to hit this bug? I often step on it both at work and at home. It's easily reproducible, for example, with pop-up messages that appear on a different desktops (for example, it happens often for me with the "Update complete" popup message from PackageKit). That is, the pop-up message appearing on a different desktop somehow gets into the list of windows for active desktop.
Created attachment 128080 [details] [review] Patch Only skip the first window if it's focussed Normally, if the focussed window is in the list of windows to switch among, it's first. However, if there are windows on other workspaces that demand attention, they're prepended to the list. Therefore, only skip the first item in the list if it's the focussed window.
Hurray! Seems to work. Thanks alot.
Seems a good patch to me! Committed with thanks. FIXED.
Created attachment 128243 [details] [review] The patch to remove windows requiring attention from Alt+Tab list Okay, I spoke too early :-( I wrote initially after I've worked with the patch for several hours and haven't observed the bug anymore, but it seems I'm so much used to this bug that I'm avoiding it subconsciously. The patch above doesn't really fix anything. Anyway, the patch was of a great help in the sense that it have pointed me out where's the actual logic for switching windows. Now I did some debugging and here's what I found. The function meta_display_get_tab_list() is meant to return a list of windows through which to cycle. At the end of this function there's a piece of code that prepends to the beginning of the list all windows from OTHER workspaces which require attention (the wm_state_demands_attention field is set). This is the source of the problem. I think the original intention of the author of that patch was to force user to switch to windows requiring attention in the first place. However, the Alt+Tab logic is not able to switch workspaces, thus this simply doesn't work - you press Alt+Tab, it tries to switch to a window on another workspace and naturally fails. Thus nothing changes which is pretty nuisant. But even if metacity would be fixed to be able to switch to windows on other workspaces this would make things even worse. By adding windows from other desktops into the list (more than that, into the beginning of the list!) the Alt+Tab switching process is made unpredictable - you never know to which window you will switch after you press it. Besides, many programs like to "require attention" for no real reason - for example, both XChat (often) and firefox (less often) do it. I often work with several windows at once (e.g. a terminal and a editor) in blind mode, and having Alt+Tab behaving consistently is a very important condition, otherwise I have to distract from doing actual work and check what Alt+Tab actually did every time (and I use it pretty often). Thus I would propose just to remove the code in meta_display_get_tab_list() that adds windows requiring attention to the tab window list. I have attached a patch that does just this. The previous patch should be unrolled.
(In reply to comment #7) > By adding windows from other desktops into the list (more than that, into the > beginning of the list!) the Alt+Tab switching process is made unpredictable - > you never know to which window you will switch after you press it. Besides, > many programs like to "require attention" for no real reason - for example, > both XChat (often) and firefox (less often) do it. That's a problem of the applications, and those should be fixed instead. > Thus I would propose just to remove the code in meta_display_get_tab_list() > that adds windows requiring attention to the tab window list. The whole point of the urgency hint is that you need to be able to switch to these windows easily. Otherwise urgency would not make any sense at all. See bug #333548 for more discussion about this.
Still, you didn't answer to my first argument that blind window switching is made unpredictable.
Upgraded to Fedora 11 (metacity 2.26.0). Hello, the old annoying bug! :-(((
I personally completely agree with Andrew Zabolotny. This unconsistent behaviour is one of the things that I hate the most in Gnome and one of the reasons why I sometimes want to switch back to KDE (there is no such problem there).
I think it's pretty simple: - Keep the behavior where demands-attention windows are added to the desktop - Make switching to that demands-attention window switch workspaces It's obviously a bug to have something in alt-tab that you can't switch to, but the idea that it should be simple to switch to a window that wants your attention makes a lot of sense. In terms of wanting to be able to switch without thinking and not get warped off to some other desktop, well, to me that's a question of why your attention is being demanded that much. - I no longer see Firefox demanding my attention when it finishes loading a page on a different workspace - I think they stopped doing that - You can configure X-Chat with "Blink taskbar on" in the "Alerts" section of preferences.
*** Bug 587921 has been marked as a duplicate of this bug. ***
*** Bug 592971 has been marked as a duplicate of this bug. ***
Yeah sounds good to me.
Fine with me too. And thanks, Owen, for pointing how to disable attention request from XChat. I didn't know "blink taskbar" means "demand attention".
I've long experienced this bug as well, on multiple machines. One of them runs dual monitors in zaphod-mode; I wonder if that complicates matters?
This still happens with 2.28. It is still very annoying.
*** Bug 536769 has been marked as a duplicate of this bug. ***
Review of attachment 128243 [details] [review]: (Owen already reviewed this patch in comment 12)
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports in Bugzilla which have not seen updates for many years. If you can still reproduce this issue in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/metacity/-/issues/ Thank you for reporting this issue and we are sorry it could not be fixed.