GNOME Bugzilla – Bug 305259
Should not set SKIP_TASKBAR on dialogs (behavior can be determined from _NET_WM_WINDOW_TYPE)
Last modified: 2005-10-01 20:58:10 UTC
1. run gedit 2. press ctrl+f to open the find dialog 3. press alt-tab Now you can't focus the find dialog no matter how many times you press alt+tab. Appears to affect any window that's "transient for" another window, but not modal, e.g. the cookie dialog in firefox, prefs dialog in gnome-terminal, prefs dialog in rhythmbox, etc.
*** Bug 303148 has been marked as a duplicate of this bug. ***
Interesting... These dialogs set _NET_WM_STATE_SKIP_TASKBAR, and due to the change from bug 106249 that means that these windows don't appear in the alt-tab list either. What's the correct behavior? I don't like focusing the dialog when its parent is selected, because that is treating the dialog like it is modal (see also bug 164716). But do we want to add SKIP_TASKBAR windows back to the alt-tab list? Do we need a new EWMH type to fine tune _NET_WM_STATE_SKIP_TASKBAR? Or is this a bug in the applications that set this hint? Personally, I think I'd lean towards saying this is a bug in the applications for setting SKIP_TASKBAR, as metacity/libwnck should do that manually for dialogs because of the following sentence from the EWMH: Applications should not set [_NET_WM_STATE_SKIP_TASKBAR] if _NET_WM_WINDOW_TYPE already conveys the exact nature of the window. Rob, Havoc: thoughts? Am I reading the EWMH right? Should we bring this up on wm-spec-list?
> These dialogs set _NET_WM_STATE_SKIP_TASKBAR, and due to the change > from bug 106249 that means that these windows don't appear in the > alt-tab list either. What's the correct behavior? I don't like > focusing the dialog when its parent is selected, because that is > treating the dialog like it is modal (see also bug 164716). But do > we want to add SKIP_TASKBAR windows back to the alt-tab list? _NET_WM_STATE_SKIP_TASKBAR seems to get set as a result of gtk_window_set_transient_for(). If you click on the app in the taskbar it gives the transient window focus. I think that's reasonable for alt+tab.
There could be more than one transient window though. It seems like the only reasonable solution is to revert the behavior. It might be neat to have some sort of visual indication in the alt-tab list that shows that these are transient windows, like have then be smaller and shown under the main window or something.
alt+tab to the main window should focus the transient window, I would say is the intent. I don't know why gtk would set SKIP_TASKBAR manually, I don't think that's right.
Havoc: that would still cause key navigation problems--the user would be unable to alt-tab to the main window. (Well, unless you want to force keynav-only users to dismiss the transient first, but that's treating it like a modal window) I'm going to refile against gtk+ since Havoc seems to agree with my reading (see comment 2) that SKIP_TASKBAR should not be set on the dialogs.
Elijah, gtk does not set SKIP_TASKBAR on the dialogs, at least my debugger doesn't stop in gdk_window_set_skip_taskbar_hint when I open a dialog. I think metacity itself sets that: window.c: case META_WINDOW_DIALOG: case META_WINDOW_MODAL_DIALOG: /* only skip taskbar if we have a real transient parent */ if (window->xtransient_for != None && window->xtransient_for != window->screen->xroot) window->skip_taskbar = TRUE;
Oh, right... oops. :) Selecting "reassign to owner of selected component" so that this actually gets assigned back to us.
This bug is only about metacity's bug of adding skip_taskbar when it shouldn't; the issue mentioned in comments 5 and 6 is covered in more detail in bug 309481.
Created attachment 49339 [details] [review] Make the code do what it says it does Hehe, so I noticed in trying to fix this bug that there's a comment in window.h that wm_state_skip_taskbar and wm_state_skip_pager are only true if the client made the request rather than us deriving the information from the window type. But then we go ahead and set the hint, get notified that the hint has been set, and then respond to it as if it was the application that set the hint instead of us. The fix is pretty simple though.
Hey Elijah, I'm still seeing the bug if I follow the steps in the original bug report. Removing the clause that Matthias pasted seems to fix it though: --- src/window.c 2 Jun 2005 15:47:37 -0000 1.388 +++ src/window.c 18 Jul 2005 18:38:34 -0000 @@ -5983,12 +5983,6 @@ recalc_window_features (MetaWindow *wind case META_WINDOW_DIALOG: case META_WINDOW_MODAL_DIALOG: - /* only skip taskbar if we have a real transient parent */ - if (window->xtransient_for != None && - window->xtransient_for != window->screen->xroot) - window->skip_taskbar = TRUE; - break; - case META_WINDOW_NORMAL: break; }
Noah: See comment 9 (which I should have been clearer about). This bug isn't about your original report anymore, as that's addressed in bug 94682 and bug 309481. Had we not found this side issue, I would have merely marked some duplicates, but no other bug mentioned this side issue so I left it open for that.
Comment on attachment 49339 [details] [review] Make the code do what it says it does See comment in window.h, /* TRUE if the client forced these on */ guint wm_state_skip_taskbar : 1; guint wm_state_skip_pager : 1; i.e. I think metacity should put them in the _NET_WM_STATE if window->skip_taskbar, not window->wm_state_skip_taskbar
That comment you point out is exactly the one I was trying to use in my explanation in comment 10 for making the change. I guess I wasn't clear, so let me try again: If metacity uses window->skip_taskbar for setting _NET_WM_SKIP_TASKBAR, then metacity gets notified of the _NET_WM_STATE change, and then metacity sets wm_state_skip_taskbar thinking that the client made the change--i.e. that comment in window.h is a lie if we set based on window->skip_taskbar. Also, the EWMH says that "This hint should be requested by the application, i.e. it indicates that the window by nature is never in the taskbar. Applications should not set this hint if _NET_WM_WINDOW_TYPE already conveys the exact nature of the window." That technically doesn't rule out the WM setting it when the client didn't, but it does seem to be its intent.
So, um, I feel kind stupid now. :/ I seem to have been really loopy in regards to this bug. I first accuse gtk+ of setting skip_taskbar when they don't, then I accused the metacity code of setting wm_state_skip_taskbar erroneously when it doesn't. I don't think my previous reading of the EWMH makes so much sense either, as it's good for the WM to hint pagers/tasklists etc. about what its policies are rather than depend on them to figure it out (which in particular is important for making the alt-tab list the same as the taskbar list). However, it does seem strange that libwnck code tries to figure this out anyway... So now I'm inclined to mark this as a duplicate of bug 309481 because no issue other than the original one reported remains. But I've made so many other mistakes on this bug, so I should probably have someone confirm that this is the right thing to do...
*** This bug has been marked as a duplicate of 309481 ***