#15 [svn 564] Keyboard shortcut loss in "click" focus model

closed-fixed
nobody
None
5
2012-01-03
2012-01-01
John Doe
No

Here is my test case, as simple and replicable as I could make it:

1) I compiled JWM svn 564 with "./configure --prefix=/usr; make" and installed it with the example configuration file (jwmrc) that comes in the tarball.

2) Start Xorg; test with Alt-1, Alt-2 etc. (the desktop switchers) that keyboard shortcuts work.

3) From JWM's menu start Firefox; close it with the mouse (click on the top-right "X" button).

4) Repeat step 2, to verify that the keyboard shortcuts still work.

5) Now leave Xorg and switch jwmrc from the default focus model "sloppy" to focus model "click".

6) Repeat the above steps 2-4.

The effect: with focus model "click", keyboard shortcuts work *before* closing Firefox, but no longer *afterwards*. I get this effect reliably, 100%, and also in very different setups. Here are a few observations related to the effect:

- The effect is *not* limited to Firefox (or GTK programs more generally).
- The only program on my computer that does *not* show the effect is xterm.
- It happens *only* if there are no other windows (beyond the one that will be closed).
- It does *not* happen when closing a program with Alt-F4.
- The regular Xorg shortcuts still work (Ctrl-Alt-Backspace etc.).
- Measures like mouseclicks on the desktop, opening and closing the menu, etc., do not bring the keyboard shortcuts back.
- Starting programs (e.g., Firefox again) does bring the shortcuts back.
- From memory: I recall having seen the effect already in JWM svn 562, but not in JWM 2.1.0. Have not used anything in between these versions.

Discussion

  • Joe Wingbermuehle

    I'm unable to reproduce this with either Xorg or Xsgi with the default JWM configuration changing from sloppy focus to click-to-focus. The only X client started other than JWM and firefox is xload (which is started from the default configuration, I also tried without xload).
    What version of Xorg are you using? I have 1.10.1.

     
  • John Doe

    John Doe - 2012-01-02

    I am on Xorg server 1.11.3, libX11 1.4.4, and xcb 0.3.8 ("ldd" shows that libX11 does use xcb).

    Well, if you cannot reproduce the problem, then you can't solve it, of course. For future reference, here is my analysis so far:

    For closing with the mouse (where the shortcuts are lost on my computer when the focus model is "click") vs. closing with the keyboard (where the shortcuts are not lost), both code-paths in "event.c" lead straightforwardly to a "DeleteClient". The main difference between the two is that closing with the mouse goes via "RaiseClient" / "FocusClient" calls first (and does so even twice: once on ButtonPress, and again on ButtonRelease). Closing with the keyboard does not do that. For the "RaiseClient" / "FocusClient" calls in the mouse-code-path, the "RaiseClient" is done unconditionally, whereas the "FocusClient" is done only if the focus model is FOCUS_CLICK. And that's exactly where I encounter the problem. So something does not like that the client gets focused very briefly before it gets deleted.

    I suspect some kind of race condition here. Perhaps the to-be-deleted window is still registered as the recipient of keystrokes, even after its ultimate deletion. XCB may factor into this, because it communicates with the X server asynchronously.

     
  • Joe Wingbermuehle

    I made a change where it only calls "FocusClient" on ButtonPress and so it uses eventTime (the time of the last event) rather than CurrentTime in the call to XSetInputFocus (revision 567 or 317).
    So if you get a chance to try it again, let me know if that changes anything for you.
    Thanks!

     
  • John Doe

    John Doe - 2012-01-03

    Thank you for the change in SVN 567. It is better (cleaner) code at that place than the code that was there before. But, to my big surprise, it made the problem worse -- with svn 567, I get the problem now for *both* of the focus models.

    However, I found the solution. Please see the attached patch. It adds one single line of code. Even if the problem does not show on your computer, you will be able to evaluate whether the patch is *conceptually* correct, or not.

     
  • Joe Wingbermuehle

    That's interesting...
    In more recent versions of JWM, JWM sends clients the TAKE_FOCUS hint if they want it. I would guess that the version of GTK you have then does an XSelectInput with the revert_to field set to None. I'm not sure if there's an easy way to test that, but I think your fix looks good. It's checked in, revision 568 (319).

     
  • John Doe

    John Doe - 2012-01-03

    My GTK+ is 2.24.8. I haven't checked their source code for the use of the revert_to field. But, clients can crash anytime, so the window manager should "play it safe" and not depend on the client's cooperation. More importantly, SVN 568 works great, thank you! As far as I am concerned, the bug can be closed.

     
  • Joe Wingbermuehle

    Marking as fixed.

     
  • Joe Wingbermuehle

    • status: open --> closed-fixed
     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks