Re: [dev] [tabbed] how focusing is handled

From: Roman Z. <romanz_AT_lavabit.com>
Date: Fri, 23 Sep 2011 02:30:06 +0200

On Thu, Sep 22, 2011 at 05:34:32PM -0400, Benjamin R. Haskell wrote:
> On Thu, 22 Sep 2011, Roman Z. wrote:
>
> >On Wed, Sep 21, 2011 at 09:48:11PM +0200, Roman Z. wrote:
> >>Currently, if you run a program in tabbed and move the mouse
> >>away from that window, the program will not respond anymore.
> >>
> >>Since this is much like how X behaves when you run no window
> >>manager, I've been looking in dwm code for solutions to this
> >>problem but to no avail. Maybe you can tell me what part of dwm
> >>handles this and I can apply it to tabbed? Or do you have other
> >>ideas?
> >>
> >>To reproduce:
> >>1. open xterm in tabbed. This hasn't worked for me with the
> >>newest version, I use revision 142.
> >>2. put the mouse inside the tabbed window and type "a". It works.
> >>3. move the mouse out of the window and type "a". Nothing happens.
> >
> >One solution is to revert the changeset 138. It has the commit
> >message: "removing XSetInputFocus() calls to be ICCCM compliant
> >again. Thanks to Thomas Adam".
> >
> >Please consider reverting this changeset in upstream since you now
> >know that it introduced a bug.
>
> Confirming that reverting 138 worked here, too:
>
> changeset: 138:5eff0bc41822
> user: Enno Boland (tox) <tox_AT_s01.de>
> date: Mon Apr 26 22:30:27 2010 +0200
> summary: removing XSetInputFocus() calls to be ICCCM compliant again. Thanks to Thomas Adam fixes tabbed for me, too, under dwm.
>
> It'd also be nice if the 'command' of 'tabbed [-d] [-v] command'
> were optional. Not sure how hard that'd be. It was weird to have
> to test it differently based on what version I was testing. I'll
> look at it later (instead of just complaining) if someone doesn't do
> it first.
>
> --
> Best,
> Ben
>

Only reverting 138 will not do the trick, as new problems arise.
Now, focus() will imply a XSetInputFocus on the selected subwindow.
This can steal the input focus from any other window. For example,
focus() is called on EnterNotify, (when the mouse enters tabbed)
independent of whether tabbed is focused or not.

You can reproduce it using dwm as window manager by running xterm in
tabbed, focusing another window, holding the key "x" and repeatedly
moving the mouse in and out of the tabbed window. Sooner or later,
some of the x'es will be passed to the xterm in tabbed even though it's
not focused by the window manager.

So I removed the handler for EnterNotify. I don't know why it was added
in the first place, but I don't see any downside after removing it
either.

There are more places where focus is called but XSetInputFocus should
not be called. For example in the XFocusChangeEvent/FocusIn handler,
maybe in expose() too.

I attached a patch for 144 which fixes things for me, but I'm not
confident that it works without errors. Especially on different
machines with different setups.

Received on Fri Sep 23 2011 - 02:30:06 CEST

This archive was generated by hypermail 2.2.0 : Fri Sep 23 2011 - 02:36:03 CEST