GNOME Bugzilla – Bug 116248
WM keynav breaks on window close
Last modified: 2004-12-22 21:47:04 UTC
Under some circumstances when a window is closed (for instance, if it's a child dialog of a window which rejects focus), metacity can get into a state where no window's border has the "focussed" decoration visuals, and Alt-TAB doesn't cycle focus. Clicking on a focussable window titlebar corrects the problem. Note that when in this state, Ctrl-Alt-TAB doesn't do anything either (!). To reproduce: start GOK without StickyKeys enabled. A dialog will appear saying "Gok has enabled sticky keys....". Press spacebar to activate the "OK" button on the dialog. Dialog closed, focus is in indeterminate state. Now Alt-TAB does nothing.
Definitely an accessibility stopper.
This is a hugely old bug we've never figured out. There's already an open bug for it I'm pretty sure.
This seems to be related to but not the same as bug 84564. If WM_SET_FOCUS ois used to specify what window should request focus but the client declines tje opffer of focus how does metacity know that this has happended. Should metacity create a timeout handler and if some window has not requested focus when the timeout has expired then the focus be given to some other window?
Created attachment 18516 [details] [review] Proposed patch to gok
There seem to be two separate complaints here: 1) No window has focus 2) Alt+Tab and Ctrl+Alt+Tab has no effect. The proposed patch to gok seems to fix the second problem.
Padraig, your patch looks harmless to my untrained eye. I gave it a try, I do not lie, please apply. I'd like to leave it open for a bit though, so that we can test at length before forgetting this delta. I am getting some wonkiness today that I suspect is related to my gnome keyboard accessibility settings, though I am unsure... I don't think it is related to your patch.
I have applied the patch to gok CVS HEAD.
Padraig could you try this: 1 start gok (such that the sticky keys info dialog comes up) 2 move the mouse into the dialog, 3 move it back to the gok window, repeat 2,3... The behaviour is such that focus tracks the mouse even though that preference is not set.
Created attachment 18525 [details] [review] New patch for gok
David, Does the new patch improve things?
Padraig, the patch does improve things for me. Thanks. This callback is called fairly often, I suppose it is okay traverse the top levels... shouldn't eat too much resources I guess. Please apply this patch if you feel comfortable with it.
I have applied this patch. It has the strange effect that when dialog box is closed keyboardfocus returns to the terminal window from which gok was launched but metacity does not show that window as having focus.
Padraig, does you patch to bug 118105 fix this latter behaviour?
No. Bug 118105 is not related to the problem I described above. It seems that after gok calls XSetInputFocus() setting focus to PointerRoot keyboard focus reverts to previous terminal window but metacity is not aware of it.
Because of bug 118865 the proposed gok patch will need to be reverted. The problem in metacity seems to be what happens if WM_TAKE_FOCUS client message is sent to a window and this does not result in XSetInputFocus being called.
Apologies for spam... marking as GNOMEVER2.3 so it appears on the official GNOME bug list :)
*** This bug has been marked as a duplicate of 84564 ***