After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 305259 - Should not set SKIP_TASKBAR on dialogs (behavior can be determined from _NET_WM_WINDOW_TYPE)
Should not set SKIP_TASKBAR on dialogs (behavior can be determined from _NET_...
Status: RESOLVED DUPLICATE of bug 309481
Product: metacity
Classification: Other
Component: general
unspecified
Other Linux
: High normal
: ---
Assigned To: Metacity maintainers list
Metacity maintainers list
: 303148 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2005-05-23 21:50 UTC by Noah Levitt
Modified: 2005-10-01 20:58 UTC
See Also:
GNOME target: ---
GNOME version: 2.9/2.10


Attachments
Make the code do what it says it does (1.53 KB, patch)
2005-07-18 02:27 UTC, Elijah Newren
reviewed Details | Review

Description Noah Levitt 2005-05-23 21:50:19 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.
Comment 1 Noah Levitt 2005-05-23 21:52:59 UTC
*** Bug 303148 has been marked as a duplicate of this bug. ***
Comment 2 Elijah Newren 2005-05-23 22:16:00 UTC
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?
Comment 3 Noah Levitt 2005-05-24 00:27:24 UTC
> 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.
Comment 4 Rob Adams 2005-05-24 00:46:07 UTC
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.
Comment 5 Havoc Pennington 2005-05-25 21:02:00 UTC
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.
Comment 6 Elijah Newren 2005-05-25 22:49:25 UTC
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.
Comment 7 Matthias Clasen 2005-06-09 16:53:02 UTC
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;
Comment 8 Elijah Newren 2005-06-09 17:00:57 UTC
Oh, right...  oops.  :)

Selecting "reassign to owner of selected component" so that this actually gets
assigned back to us.
Comment 9 Elijah Newren 2005-07-05 17:18:24 UTC
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.
Comment 10 Elijah Newren 2005-07-18 02:27:41 UTC
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.
Comment 11 Noah Levitt 2005-07-18 18:41:23 UTC
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;
     }
Comment 12 Elijah Newren 2005-07-18 18:51:10 UTC
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 13 Havoc Pennington 2005-07-19 17:57:49 UTC
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
Comment 14 Elijah Newren 2005-07-19 18:43:50 UTC
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.
Comment 15 Elijah Newren 2005-07-21 03:17:48 UTC
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...
Comment 16 Elijah Newren 2005-10-01 20:58:10 UTC

*** This bug has been marked as a duplicate of 309481 ***