GNOME Bugzilla – Bug 350547
Panel always stays on top
Last modified: 2006-08-21 03:00:52 UTC
One of my panels (the top panel) always stays on top, even when I'm using Evince, Epiphany, Eog or Inkscape in full-screen mode. I tried fiddling with the settings in Gconf, but it all seems ok (the same settings as my bottom panel, which works like it should).
Works fine here. Can you run xprop on it and attach the output here? Does it also happen after restart?
elin:~ > xprop _NET_WM_USER_TIME(CARDINAL) = 4070005962 XKLAVIER_STATE(INTEGER) = 0, 0 WM_STATE(WM_STATE): window state: Normal icon window: 0x0 _NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_CHANGE_DESKTOP _NET_WM_DESKTOP(CARDINAL) = 4294967295 _NET_WM_STATE(ATOM) = _NET_WM_STATE_SKIP_PAGER, _NET_WM_STATE_SKIP_TASKBAR XdndAware(ATOM) = BITMAP _MOTIF_DRAG_RECEIVER_INFO(_MOTIF_DRAG_RECEIVER_INFO) = 0x6c, 0x0, 0x5, 0x8, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0xf0, 0xb7, 0x10, 0x0, 0x0, 0x0 WM_HINTS(WM_HINTS): Client accepts input or input focus: True Initial state is Normal State. bitmap id # to use for icon: 0x1200024 bitmap id # of mask for icon: 0x120002b window id # of group leader: 0x1200003 _NET_WM_STRUT_PARTIAL(CARDINAL) = 0, 0, 25, 0, 0, 0, 0, 0, 0, 1023, 0, 0 _NET_WM_STRUT(CARDINAL) = 0, 0, 25, 0 _NET_WM_ICON(CARDINAL) = 24, 24, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 4278190080, 4278190080, 4278190080, 4278190080, 4278190080, 4278190080, 4278190080, 4278190080, 4278190080, 4278190080, 4278190080, [SNIP: LOTS OF NUMBERS HIGHLY IRRELEVANT TO THIS ISSUE] _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_DOCK _MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x2, 0xbf815bd8, 0x0, 0x80e636c, 0xb77ddf2a _NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 18874373 WM_CLIENT_LEADER(WINDOW): window id # 0x1200001 _NET_WM_PID(CARDINAL) = 2843 WM_LOCALE_NAME(STRING) = "nl_NL.UTF-8" WM_CLIENT_MACHINE(STRING) = "elin" WM_NORMAL_HINTS(WM_SIZE_HINTS): program specified location: 0, 0 WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST WM_CLASS(STRING) = "gnome-panel", "Gnome-panel" WM_ICON_NAME(STRING) = "Top Panel" _NET_WM_ICON_NAME(UTF8_STRING) = 0x54, 0x6f, 0x70, 0x20, 0x50, 0x61, 0x6e, 0x65, 0x6c WM_NAME(STRING) = "Top Panel" _NET_WM_NAME(UTF8_STRING) = 0x54, 0x6f, 0x70, 0x20, 0x50, 0x61, 0x6e, 0x65, 0x6c
Hmm... I was able to reproduce this after a reboot (yesterday and today), but right now I can't reproduce after killing gnome-panel. The xprop output from above is on a correctly functioning panel. Please leave this bug open for a while... when I encounter the problem again I'll provide the xprop info for the malfunctioning panel.
Thanks. I'll mark it as NEEDINFO since it will make my life easier and you'll see the bug more prominently in your "My Bugs" page.
Got it: _NET_WM_USER_TIME(CARDINAL) = 4145779381 XKLAVIER_STATE(INTEGER) = 0, 0 WM_STATE(WM_STATE): window state: Normal icon window: 0x0 _NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_CHANGE_DESKTOP _NET_WM_DESKTOP(CARDINAL) = 4294967295 _NET_WM_STATE(ATOM) = _NET_WM_STATE_SKIP_PAGER, _NET_WM_STATE_SKIP_TASKBAR XdndAware(ATOM) = BITMAP _MOTIF_DRAG_RECEIVER_INFO(_MOTIF_DRAG_RECEIVER_INFO) = 0x6c, 0x0, 0x5, 0x8, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0xf1, 0xb7, 0x10, 0x0, 0x0, 0x0 WM_HINTS(WM_HINTS): Client accepts input or input focus: True Initial state is Normal State. bitmap id # to use for icon: 0x1200024 bitmap id # of mask for icon: 0x120002b window id # of group leader: 0x1200003 _NET_WM_STRUT_PARTIAL(CARDINAL) = 0, 0, 25, 0, 0, 0, 0, 0, 0, 1023, 0, 0 _NET_WM_STRUT(CARDINAL) = 0, 0, 25, 0 _NET_WM_ICON(CARDINAL) = 24, 24, ... _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_DOCK _MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x2, 0xbff1b448, 0x0, 0x80e636c, 0xb77e3f2a _NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 18874373 WM_CLIENT_LEADER(WINDOW): window id # 0x1200001 _NET_WM_PID(CARDINAL) = 2816 WM_LOCALE_NAME(STRING) = "nl_NL.UTF-8" WM_CLIENT_MACHINE(STRING) = "elin" WM_NORMAL_HINTS(WM_SIZE_HINTS): program specified location: 0, 0 WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST WM_CLASS(STRING) = "gnome-panel", "Gnome-panel" WM_ICON_NAME(STRING) = "Top Panel" _NET_WM_ICON_NAME(UTF8_STRING) = 0x54, 0x6f, 0x70, 0x20, 0x50, 0x61, 0x6e, 0x65, 0x6c WM_NAME(STRING) = "Top Panel" _NET_WM_NAME(UTF8_STRING) = 0x54, 0x6f, 0x70, 0x20, 0x50, 0x61, 0x6e, 0x65, 0x6c
I use a metacity keybinding to make windows fullscreen. If I press it, the panel stays on top for applications like Nautilus and Gossip. If I use the fullscreen menu item in Evince or Epiphany, there is no problem. Note that I have 2 panels, but only the top panel stays on top. Btw, the menubar of eg. Nautilus stays below the panel.
Created attachment 70618 [details] Screenshot of "non-maximized" window
Created attachment 70619 [details] Screenshot of "maximized fullscreen" window
cc'ing my metacity hero who might have an idea about this bug.
Oh, fun -- comment 6 is the exact opposite of what bug 343115 comment 4 claims. :( I'll try to find some time to look into it (kind of swamped until after my defense that hopefully happens late September, though). I think the x properties of the wanted-to-be-full-screen-window would be more interesting than those of the panel, but I'll probably need to make a patch to add debugging spew and get a volunteer to run with it and duplicate the problem.
There were about 3-4 fullscreen bugs that I found in metacity (> 2.12.x, though one only affects 2.15.21 and newer). I've created a patch in bug 343115; could you test it out?
Elijah, confirming the mentioned patch fixes the fullscreen issues reported in this bug. Please commit!
Btw: + /* Workaround braindead legacy apps that don't know how to + * fullscreen themselves properly. + */ Not all apps know about fullscreen. Nautilus does not, for instance. Thanks to a metacity keybinding I'm able to get those apps fullscreen nonetheless. I'm not sure if that is "broken".
(In reply to comment #13) > Btw: > > + /* Workaround braindead legacy apps that don't know how to > + * fullscreen themselves properly. > + */ > > Not all apps know about fullscreen. Nautilus does not, for instance. Thanks to > a metacity keybinding I'm able to get those apps fullscreen nonetheless. I'm > not sure if that is "broken". That comment was in reference to applications that have their own "fullscreen" function (and thus are aware of such ability), but implement it incorrectly. (In reply to comment #12) > Elijah, confirming the mentioned patch fixes the fullscreen issues reported in > this bug. Please commit! Awesome, thanks for trying it out so quickly! I'll mark this bug as a duplicate, and get the patch into the metacity release tomorrow (in my timezone anyway...) if I can find one or two additional testers. :) *** This bug has been marked as a duplicate of 343115 ***