GNOME Bugzilla – Bug 128200
wrong window focused after minimizing focus window
Last modified: 2004-12-22 21:47:04 UTC
Description of Problem: Steps to reproduce the problem: 1. open two or three windows in gnome 2.4 2. minimise one of them via the task bar Actual Results: the window 'below' the one you just minimised is not selected automatically Expected Results: this wasn't the case in gnome 2.2, it really should be, shouldn't it? How often does this happen? Every time. Additional Information: Running Fedora Core 1. gnome rules .... apart from that :)
Where is the keyboard focus after this? It's supposed to be on the most recently used window.
it's on the panel at that point; so the panel has focus.
Hrm, can panel be filtered from that MRU list? That seems like the 'right' thing, no?
No, I don't think focusing a different window is right. I believe this is NOTABUG both from the point of view that the panel is where the mouse is and it thus deserves to be the focused window (at least in sloppy/mouse focus modes) and because trying to change this behavior could result in complications: If we try to remove the panel from the MRU list, we'll probably end up with another race condition like the one that currently exists under certain conditions for normal window closing/minimization in mouse or sloppy focus modes (see bug 131582).
Hmmm, I obviously ignored click-to-focus when I wrote my previous comment. I should probably get thwacked for that... This is a duplicate of bug 107681. However, it appears that both Metacity and libwnck will need to be changed to obtain the correct behavior so I'll leave this bug open. See my comment in 107681 for what I believe is the appropriate fix (namely, get a _NET_MINIMIZE_WINDOW hint in the EWMH spec so that libwnck can tell metacity to minimize the window, and then metacity can automagically handle which window to focus instead of having libwnck guess which one it should be).
Created attachment 28745 [details] [review] Metacity portion of patch to allow correct window to be focused after minimization from libwnck After coding up this patch (and the corresponding one that I'm about to post to bug 107681, which is also required), I realized that this might not be the best way to do this. It may be better to stick with the old WM_CHANGE_STATE and XIconify method, merely for backward compatibility. But it's time for bed so I'm posting what I have now.
Comment on attachment 28745 [details] [review] Metacity portion of patch to allow correct window to be focused after minimization from libwnck Ignore this patch. It was totally wrong (see bug 122640 for why; basically I shouldn't have used _NET_WM_STATE_MINIMIZED). However, there is a patch that fixes this bug attached to bug 120100.
The patch in bug 120100 was a hack that was understandably rejected. Back to square one. However, maybe _NET_WM_STATED_MINIMIZED will be the right way to do things after all; the wm-spec list seemed to agree that such an addition to the spec sounded okay, it's just that no one has decided to do it yet. Also, see bug 102665 for the analogous but reverse issue--i.e. when unminimizing a window from the tasklist it should usually be focused. I'm really tempted to mark this bug and 107681 as dups, even though the solution may require modifying both libwnck and metacity...
Created attachment 31270 [details] [review] Focus the correct window after minimizing via the tasklist So, the _NET_WM_STATE_MINIMIZED_TO_TASKBAR stuff might be a way to avoid this problem within Gnome in the future. However, it would still be nice to have Metacity behave appropriately for tasklists/pagers/etc that use the current spec. So here's a solution that doesn't require a EWMH change. The patch works by tracking not just the current focus_window, but also the previous one. When the user clicks on the tasklist, the panel is the one that becomes the focus_window. So, in those cases, we check to see if a DOCK or DESKTOP is the focus_window and whether the previous focus window is the window being minimized. In those cases, we can safely focus the new default window. This patch fixes the problem for both click and sloppy focus methods (this problem wasn't an issue for mouse focus).
Comment on attachment 31270 [details] [review] Focus the correct window after minimizing via the tasklist Maybe clear previously_focused_window in meta_window_free(), to avoid dangling pointer. Looks like a reasonable short-term hack for 2.8, though I'd almost be inclined to put it only on the 2.8 branch and not on HEAD.
Created attachment 31288 [details] [review] Updated patch; clear previously_focused_window in meta_window_free
Comment on attachment 31288 [details] [review] Updated patch; clear previously_focused_window in meta_window_free OK with me to commit this if you get release team approval as required. It might not hurt to add a "FIXME bad hack" in there somewhere, with a link in the FIXME comment to a new bug for "fix it really"
Release team said no; setting the 2.8.x milestone.
committed.