GNOME Bugzilla – Bug 515773
Session exits with Window manager warnings re: focus window, CurrentTime and a timestamp of 0
Last modified: 2008-02-21 03:34:38 UTC
Although the window manager (ie: metacity) warnings are reported in the ~/.xsession-errors file upon user session exit, there are no apparent problems with the session itself. It can be problematic when trying to diagnose/debug other problems/bugs since the reporting may only confuse and clutter the .xsession-file with unrelated messages. Either eliminate the reason why these messages are being reported upon session exits *or* eliminate these error messages, if they are extraneous, from being reported in the error logs. Other information: The aforementioned messages from the ~/.xsession-errors are as follows: Window manager warning: CurrentTime used to choose focus window; focus window may not be correct. Window manager warning: Got a request to focus the no_focus_window with a timestamp of 0. This shouldn't happen!
Are these messages not being produced by the behaviour of other applications simultaneously with user session exit?
Hi Thomas, Sorry for the late reply. It may be that these messages are being produced by other applications upon user session exit; however, the messages are being printed to the user's .xsession-errors as shown above with the only reference to which application being at the beginning of the error messages (ie: "Window manager warning:"). In this case, metacity is the default window manager that is called by gnome-session and served as the starting point application to reference for these errors/warnings. This bug is easily reproduced by the following steps: 1. Login to a user's default GNOME session via gdm 2. Logout back to gdm's login screen 3. Switch to an unused console tty (I used tty1, Alt-Ctrl-F1) 4. Login via mingetty on the console tty as root 5. Go to the user's home directory to examine .xsession-errors I hope this helps in resolving this annoyance. Please let me know if there is anything else that you would like me to help with. Francis Shim
Would you prefer if all these messages were prefixed with the name of the application which caused them, rather than the window manager? For example, in my ~/.xsession-errors I have: Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0x3200062 (Buddy List) This is clearly an error caused by Pidgin and caught by Metacity. Would it be more acceptable for this to say Window manager warning: Pidgin: Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0x3200062 (Buddy List) or perhaps Pidgin: Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0x3200062 (Buddy List)
Your proposals would improve the situation; however, if the situation is as indicated that the window manager (ie: metacity) has received a request from a client (eg: Pidgin) then the warning or error message should reflect as informatively as possible what has occurred for the reader of the message. In particular, it should be helpful to point to the offending application so that attention can be directed to the appropriate software. Using your example, when I see "Buddy List" in the current existing message, it is understandable that you can infer that the offending error came from an application that uses a "Buddy List", in this case, Pidgin; however, you could be running multiple instances of different IM applications (eg: aMSN, IRC, X-Chat), each with a "Buddy List" and it would not be as obvious. Your proposal where it is possible to include the offending application name in the message would alleviate this situation and the error report would be sent to the maintainers of Pidgin, in this example. From your list of proposals, I modified what would be best to suggest the following: Window manager ("metacity") warning: Buggy client ("pidgin") sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0x3200062 (Buddy List) Now, to return to the original messages, it would help the triaging process if the error/warning messages were modified to follow this suggested template as followed: Window manager ("metacity") warning: Client ("calendar") used CurrentTime to choose focus window; focus window may not be correct. Window manager ('metacity") warning: Client ("calendar") request to focus the no_focus_window with a timestamp of 0. This shouldn't happen! NOTE: the use of "calendar" as the offending application is completely arbitrary; however, it is used for illustrative purposes. I hope this helps.
Sounds great and all...how do we determine what the sending process was? (That's always been one of my big gripes with X messages...) Was I just missing something obvious this whole time? I'm going to feel dumb if that's the case...not that it'd be the first time, though.
It may not be easy, but it should not be impossible. It really depends on how much information is in the errant client request. If it is true that "metacity" has access to the full errant client request that it is complaining about then it follows that as a server-like process it must also have enough information to be able to tell which client it is serving. "Metacity" is a window manager so it must have at least access to the client window ID. If there is a mapping from the client window ID to a client information structure then there really should be access to the client network location and PID. Once you have the client PID then we should be able to derive the client application name. I know that this is a little long-winded, but I have not examined the "metacity" source as yet to determine this feasibility. I hope this helps.
EWMH does let us get the PID of a window owner ("_NET_WM_PID")-- we use it at present to nuke applications which won't let us close their windows in a timely manner.
Great! So it is possible to report the offending client's name and that would help to direct error/warning messages as those that we have mentioned to their proper triaging center. At the moment, we probably should treat this bug report as a "metacity" report so that this helpful improvement can be implemented within "metacity"; however, it should everntually be used for other window managers that might be used in place of "metacity". If it is still relevant, we can then forward this bug report to the proper maintainers of the errant client that produced the situation in the first place.
(In reply to comment #6) > It may not be easy, but it should not be impossible. It really depends on how > much information is in the errant client request. If it is true that > "metacity" has access to the full errant client request that it is complaining > about then it follows that as a server-like process it must also have enough > information to be able to tell which client it is serving. Why? Just because metacity has the request doesn't mean that the request has any information that identifies the requestor. We can guess that a request to raise, say, gaim, came from gaim itself, but that's a potshot. There's all kinds of tasklists, devilspies, superswitchers, etc. that could have done it, as well as any other random app... > "Metacity" is a window manager so it must have at least access to the client > window ID. Sure, it has access to the client window ID of all clients. How does it tell which one sent the message? Mapping client ID->PID is trivial (given the EWMH hints, as Thomas points out). Given the client ID, we can also trivially get application name, titlebar string, window size, most recent interaction time, and dozens of other bits of information. That's easy. However, how do we get the client window ID? _That_ is what I have never figured out.
Also worth noting is that the current EWMH specification for _NET_ACTIVE_WINDOW provides a specific field for the requestor to fill in the window ID of their currently focused window. If the window manager could obtain that already, there would be no point in having a client app manually package it into the message. Now, this may sound like it solves the problem, however... The focus window ID part is somewhat newer in the spec, and when I provided a patch to gtk+ to implement this, Owen and Matthias instantly checked out the spec and said it was broken (basically that the app couldn't figure out this information reliably). Before I could commit to gtk+, I had to remove that part of the patch and leave the window ID unspecified. Also, there are many apps that manually send _NET_ACTIVE_WINDOW messages, and few if any probably adhere to this particular part of the spec. Sorry, but I just don't see how this request isn't CANTFIX.
Okay, it appears that there is a problem with regards to implementation details in how one could fix this problem; however, these warning messages will only serve to clutter up .xsession-errors and confuse other debugging issues as it stands. From what Elijah has revealed the messages occur as a result of the design details of the client-server policies and data structures with a regular event that would need more information in those data structures. So the options are to fix the policy and/or the data structures so the required information is available; otherwise, continue with these extraneous messages until the buggy clients fix themselves. It would be better to implement a more robust policy which may involve digging more into the core client-server structure of metacity, gtk+ and Xorg windows than to simply let this sit by the wayside.
(In reply to comment #11) > From what Elijah has revealed the messages occur as a result of the design > details of the client-server policies and data structures with a regular event > that would need more information in those data structures. > > So the options are to fix the policy and/or the data structures so the required > information is available; otherwise, continue with these extraneous messages > until the buggy clients fix themselves. I think what you are asking is for a redesign of X, a lack of which has often been publicly lamented over the last twenty-five years or so, but which is rather beyond what can be acheived in a metacity bug. You might want to ask on one of the X mailing lists: http://www.x.org/wiki/XorgMailingLists .