GNOME Bugzilla – Bug 496491
No focus if metacity is killed
Last modified: 2020-11-06 20:07:34 UTC
Please describe the problem: If metacity dies or is killed it leaves the desktop in a state where you can't focus any window. I know metacity practically never dies of its own accord, but in ROX-Session the easiest way to change window manager is to kill the old one then type the new one into a dialog that ROX-Session pops up when it notices the window manager has disappeared. After killing metacity you have to resort to dropping to the console and running the command with DISPLAY set explicitly. Steps to reproduce: Kill metacity. Actual results: I can't start a new window manager by typing in ROX-Session's dialog or a terminal because no windows accept focus. Expected results: All other window managers I've used leave the desktop in a sort of sloppy/follows mouse focus mode when they're killed. Does this happen every time? Yes Other information:
I don't remember the details here, but generally I think focus post-kill depends on whether the last caller of XSetInputFocus() used RevertToNone. RevertToNone is always wrong/evil - since the "None" focus state is wrong/evil. Pretty much a bug in the X protocol that this state exists. Unfortunately, here's the issue: any app in the whole desktop could have called XSetInputFocus() with RevertToNone. I don't think metacity ever does. IIRC there's some other case that results in None focus too, maybe RevertToParent when the parent is not mapped (wild guess), something like that. A non-RevertToNone case might be harder to avoid, and is more likely to be caused by metacity. (OK, I should probably research this instead of just guessing) A key to debugging this would be: what is focused at the moment you kill metacity? And for bonus points, who did the XSetInputFocus() that focused it? A workaround, you may find that using the -replace or --replace feature of the new WM is more elegant than using "kill" (if your new WM does not support --replace, file a bug against it, this is standard functionality since it's the only way to cleanly switch WMs)
ROX-Session suggests that you can change which WM it uses by killing your current WM, whereupon it will put up a new dialogue asking which WM to use instead: <http://roscidus.com/desktop/node/111>. This is an incredibly broken idea because there's no guarantee you'll be able to switch to the new dialogue once you don't have a window manager any more! No sequence of user actions should ever leave X without a WM for more than an infinitesimal period of time. So for one thing, that should change. But perhaps your target WM (OroboROX, maybe? I haven't tried it) has a --replace option, and if so you should use that instead. If not, it should.
The focused window at the point I kill metacity is usually ROXTerm which is based on vte. I'll look into getting the docs for ROX-Session changed and try to implement --replace in OroboROX if it's being resurrected.
Looking for RevertToNone, on the second page of results there is one in OroboROX, you should get rid of that: http://www.google.com/codesearch?q=rox+RevertToNone&hl=en&btnG=Search+Code (not saying it causes this bug, in fact I don't see how it would, but it's still not good) If you search for just "RevertToNone" there are unfortunately zillions of apps doing it, from mozilla to xine to wxWidgets/Lesstif. All of these are bugs, most likely...
See bug 125492 regarding how revertto can be set to None when a window becomes unviewable (particularly bug 125492 comment 5).
Summing up the bug Elijah mentioned, if a window is unmapped with RevertToParent set, then the focus is set to the parent using RevertToNone, so when the parent goes away also the X server reverts to None. I guess if you just killed metacity, then frame windows would be destroyed; this might mean first reparenting the client windows out of them, causing RevertToParent to the frame, then when the frame went away a RevertToNone? Or something of that nature. However, it looks like metacity always uses RevertToPointerRoot not RevertToParent, so I'm not even sure how this would happen, except of course that any app can set focus with RevertToNone or RevertToParent. The bottom line on this bug is that metacity can't guarantee that focus of None never happens, because the WM (unfortunately) does not redirect focus requests. It is *possible* that in the specific situation here, the reason focus ends up as None has something to do with something metacity could affect, so there could be something to fix, but a categorical or definitive fix covering all situations is not possible. I'd be inclined to say "don't kill the window manager, exit it gracefully" ... then bad things won't happen. But short of that, a first (relatively) simple thing to try might be cleaning up all RevertToNone and even RevertToParent in any program running in the desktop session in question...
Are bugs 490668 and 496491 dupes of one another?
Trying again: Are bug 490668 and bug 496491 dupes of one another?
It's possible the two bugs have the same cause, but without tracking it all down I'd say the two bugs are simply similar. One bug notes that metacity doesn't make sure there is a window focused when it starts (in fact, metacity removes focus from whatever had focus whenever it starts up). This bug notes that killing metacity and leaving no window manager up results in nothing having focus. Bug 490668 is most likely a duplicate of some bug numbered in the 8xxxx range (I don't remember the exact number).
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.