GNOME Bugzilla – Bug 510871
after hiding the contact list, it sometimes loses the window border
Last modified: 2020-11-06 20:06:20 UTC
not sure if this is another metacity bug, but since it _only_ happens to empathy, i'll file it here. sometimes, when i click the status icon to show the contact list, it comes back and isn't recognized by metacity anymore. it has no window decoraction and no button in the window list. i don't know how to reproduce it, but it's pretty annoying. i have metacity 2.21.5 and empathy 2.21.5.2 installed.
this still happens with metacity 2.21.13 and empathy from svn (revision 638) and is really quite annoying as you have to either kill metacity so it is fired up automatically and then handles empathy again or you'd have to quit empathy and start it again.
I don't see how it could be an empathy bug, looks like a metacity bug to me.
i just ran empathy with xfwm4 and there is actually another strange behaviour, so i don't think it's a metacity bug: when i run empathy, it starts hidden in the tray. when i click the status icon the contact list appears with minimize, maximize and close buttons on the window decoration as it should be. now when i click the minimize button, empathy is minimized to the panel, which is correct behaviour. i can unminimize it and minimize it all over again. but when i click either the close button on the window decoration _or_ the status icon, the contact list stays on the desktop, _keeps_ the window decoration, but the minimize button on the decoration disappears as does the panel button for the contact list. after that, i can't minimize to tray anymore by clicking the status icon or the close button (the whole window decoration stays visible, except the minimize button of course, but is not functional anymore). so this is pretty weird too and not running metacity at all. with metacity however, i've had another strange behaviour which causes the contact list to flicker when i minimize and restore it to and from the the tray. it looks like the window is restored and immediately hidden and restored again. it's only a very short part of a second, but it is noticable and happens every time and _only_ with empathy. no other app flickers like that here. and no other app loses the window decoration btw... i really don't want to whine or anything, but these problems really happen here and they are very annoying sometimes. and as you can see, it also happens with another window manager than metacity.
oops, sorry, there is a misinformation: when the minimize button from the window decoration disappears, only the close button loses functionality. maximize and shade and so on still work. also i can't minimize via the status icon's context menu option "show contact list" which is checked and stays checked, when i click it after the minimize button disappeared.
ok, after xfwm4 and metacity both not working correctly with empathy i just tried compiz and with compiz it works fine. no flickering here too and no losing window decoration. maybe it's a gtk bug, but why is it only happening to empathy and not to things like liferea, deluge or rhythmbox which all behave as they should? what is empathy doing different when deiconifying from systray?
I confirm this behavior. I only have this with empathy. I'm using many application with iconify/deiconify functionality and this is the only application where it happens.
Let's reassign this bug to metacity to see what they thought.
I confirm this behavior too, happens with the following versions: metacity 2.22.0 Empathy 0.23.3 I'm using debian testing up-to-date.
The window can't be found by wnckprop (and does not show up in the pager), xwininfo however finds it: $ xwininfo xwininfo: Please select the window about which you would like information by clicking the mouse in that window. xwininfo: Window id: 23068750 "Kontaktliste" Absolute upper-left X: 16 Absolute upper-left Y: 121 Relative upper-left X: 16 Relative upper-left Y: 121 Width: 243 Height: 427 Depth: 24 Visual Class: TrueColor Border width: 0 Class: InputOutput Colormap: 0x20 (installed) Bit Gravity State: NorthWestGravity Window Gravity State: NorthWestGravity Backing Store State: NotUseful Save Under State: no Map State: IsViewable Override Redirect State: no Corners: +16+121 -1021+121 -1021-476 +16-476 -geometry 243x427+16+121 ------------------------------------------------------- $ wnckprop --window=23068750 Cannot interact with window with XID 23068750: the window cannot be found I also tried checking calls to _wnck_create_window using gdb and it did not get called for 23068750. However there are calls to wnck_window_get using this ID. Is there anything more useful I could check?
The window does not show up in _NET_CLIENT_LIST either: Window-ID: 23068750 (results from wnckprop using gdb after calls to _wnck_get_window_list from update_client_list) _NET_CLIENT_LIST_STACKING: {16777246, 60817537, 52428830, 16876311, 29360240, 46528924, 46145313, 67108874, 46158516, 46596613, 46173259, 33554435, 46359330, 67119650, 46585343, 46421121, 75497601, 60821463, 67118435, 67118313, 54528321, 14680067} _NET_CLIENT_LIST: {14680067, 16777246, 33554435, 46145313, 46158516, 46173259, 29360240, 60817537, 46359330, 54528321, 16876311, 52428830, 67108874, 46421121, 75497601, 60821463, 46528924, 46585343, 46596613, 67118313, 67118435, 67119650} ------------------------------------------------------------- xprop for that window: _NET_WM_ICON_GEOMETRY(CARDINAL) = 1035, 1, 24, 30 XKLAVIER_STATE(INTEGER) = 1, 0 WM_STATE(WM_STATE): window state: Withdrawn icon window: 0x0 _NET_FRAME_EXTENTS(CARDINAL) = 4, 4, 22, 4 _NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_MOVE, _NET_WM_ACTION_RESIZE, _NET_WM_ACTION_FULLSCREEN, _NET_WM_ACTION_MINIMIZE, _NET_WM_ACTION_SHADE, _NET_WM_ACTION_MAXIMIZE_HORZ, _NET_WM_ACTION_MAXIMIZE_VERT, _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_CLOSE, _NET_WM_ACTION_ABOVE, _NET_WM_ACTION_BELOW WM_HINTS(WM_HINTS): Client accepts input or input focus: True Initial state is Normal State. bitmap id # to use for icon: 0x1600051 bitmap id # of mask for icon: 0x1600053 window id # of group leader: 0x1600001 XdndAware(ATOM) = BITMAP _MOTIF_DRAG_RECEIVER_INFO(_MOTIF_DRAG_RECEIVER_INFO) = 0x6c, 0x0, 0x5, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x10, 0x0, 0x0, 0x0 _NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 23068752 _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL _NET_WM_USER_TIME_WINDOW(WINDOW): window id # 0x160004f WM_CLIENT_LEADER(WINDOW): window id # 0x1600001 _NET_WM_PID(CARDINAL) = 6040 WM_LOCALE_NAME(STRING) = "de_DE.UTF-8@euro" WM_CLIENT_MACHINE(STRING) = "desktop" WM_NORMAL_HINTS(WM_SIZE_HINTS): program specified minimum size: 197 by 115 window gravity: NorthWest WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST WM_CLASS(STRING) = "empathy", "Empathy" WM_ICON_NAME(STRING) = "Kontaktliste" _NET_WM_ICON_NAME(UTF8_STRING) = 0x4b, 0x6f, 0x6e, 0x74, 0x61, 0x6b, 0x74, 0x6c, 0x69, 0x73, 0x74, 0x65 WM_NAME(STRING) = "Kontaktliste" _NET_WM_NAME(UTF8_STRING) = 0x4b, 0x6f, 0x6e, 0x74, 0x61, 0x6b, 0x74, 0x6c, 0x69, 0x73, 0x74, 0x65
IIRC libwnck is just based on _NET_CLIENT_LIST, which is in turn based on the set of currently-managed windows. This window is not managed because of this: WM_STATE(WM_STATE): window state: Withdrawn To figure out why this is happening, you'd probably want to look at the metacity logs; see "Debugging logs" in this document for instructions: http://svn.gnome.org/viewvc/metacity/trunk/HACKING?view=markup See the ICCCM for WM_STATE and how transitions of state are supposed to happen. Looking at the empathy code, I bet something in libempathy-gtk/empathy-ui-utils.c is involved. I don't see anything in there that should break metacity (though I see some race conditions getting server-side state then acting on it even though it may have changed in between), but there is some weird stuff in there that other apps aren't doing, so it may break WMs in ways other apps do not.
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.