bug#745: pop-to-buffer, frames, and input focus

[Helmut Eller]

* martin rudalics [2008-08-23 14:05+0200] writes:

>> The problematic cases are
>>
>>   (let ((pop-up-frames t)) (display-buffer ...))
>>
>> for display-buffer, if the buffer was not visible before.  In this case
>> a new frame appears, which (wrongly) has the input focus.
>
> Rather "which (wrongly) has the input focus for window managers able to
> handle mapping a new frame without giving input focus to it" because
> IIUC with certain settings (focus-follows-mouse) some window managers
> automatically do give focus to the new frame.

Yes, I agree.  I didn't know before that Sawfish has a
focus-window-when-mapped option.  Situation A is probably a window
manager issue.

> I also suppose that the
> only means to take focus away from the new frame is by giving focus to
> the previously selected frame (though we can't even be sure that frame
> had focus or was risen).

I've read a little bit in the Xlib Manual[*] and here is what I learned:

If we set the focus to the old frame by calling
select-frame-set-input-focus in display-buffer we have something like a
race condition.  The window manager may decide at the same time that the
new frame should have the focus and either Emacs or the WM will win the
race.

Emacs sets the "input-hint" flag in WM_HINTS when creating new frames.
This can be seen with:

  shell$ xprop WM_HINTS
  WM_HINTS(WM_HINTS):
                Client accepts input or input focus: True
                Initial state is Normal State.
                bitmap id # to use for icon: 0xa00710
                bitmap id # of mask for icon: 0xa00712
                window id # of group leader: 0xa00001

If the input-hint flag is set, some window managers will assume that
Emacs doesn't switch the input focus by itself and so the WM does it.

In theory, Emacs could clear the input-hint flag (to stop the WM from
switching focus) and instead listen to WM_TAKE_FOCUS events.  The window
manager sends WM_TAKE_FOCUS to Emacs, when the WM thinks that Emacs
should now be focused.  Emacs can then decide to set (or not) the focus
to the appropriate frame.

I don't know how well that would work in practice or if all window
managers follow the conventions.  But if the input-hint flag is set,
Emacs has to fight with the window manager.  OTOH, some people will
prefer that the WM does all the focus switching.  I guess it's not worth
fixing situation A.  People with decent window managers will be able to
configure their preferred focus behavior anyway.

[*] http://tronche.com/gui/x/icccm/sec-4.html

>> (If the
>> buffer is already visible in some frame, that frame is raised but the
>> focus is not moved to that frame.  This is IMO correct.)
>
> I think so.  But what happens in the `pop-to-buffer' case when a _new_
> frame gets displayed.  Should we give it input-focus?

Yes.  I don't see why not.

> I suppose so from
> your situation B comments below.  So in all cases where situation A has
> Y (that is `display-buffer' fails TDTRT) `pop-to-buffer' DTRT?

Yes, right.  In this case pop-up-frames must be t when pop-to-buffer is
called.

>> For pop-to-buffer:
>>
>>   (let ((display-buffer-reuse-frames t)) (pop-to-buffer ...))
>>
>> if the buffer is already visible in a frame which has not the input
>> focus.  This should move input focus to that frame, but it currently
>> doesn't.  (If the frame has already the focus, pop-to-buffer works as it
>> should.)
>
> Do we agree on the general rule that
>
> - `display-buffer' should never try to move input focus to another (new
>   or existing) frame, while
>
> - `pop-to-buffer' should try to give input focus to the frame where
>   BUFFER is displayed 

Yes, we agree.

> (this could be the selected frame as well).

[I guess, it would be an optimization for a common case not to give input
focus to the frame that is already focused.  But despite efficiency,
it wouldn't make a difference.]

>
>> Let's call the display-buffer case, situation A and the pop-to-buffer
>> case, situation B.
> [...]
>> OK, here is what I see:
>>
>> A  B  WM         WM focus mode
>> ---------------------------------------
>> Y  N  Sawfish    follow-mouse (enter-only + focus-window-when-mapped)
>> N  N  Sawfish    follow-mouse (enter-only + !focus-window-when-mapped)
>> Y  N  Sawfish    follow-mouse (enter-exit + focus-window-when-mapped)
>> N  N  Sawfish    follow-mouse (enter-exit + !focus-window-when-mapped)
>> Y  N  Sawfish    click-to-focus (click + focus-window-when-mapped)
>> N  N  Sawfish    click-to-focus (click + !focus-window-when-mapped)
>> Y  N  Sawfish    click-to-focus (click + focus-window-when-mapped + 
>> focus-click-through)
>> N  N  Sawfish    click-to-focus (click + !focus-window-when-mapped + 
>> focus-click-through)
>
> I'm completely ignorant WRT to focus-window-when-mapped: Does this mean
> that a window that is not risen can get focus?

[Note, this "window" is X jargon.  Emacs would call this a frame.]
AFAIK, it's possible to give the focus to a window without raising it.
I guess though, that the window must be mapped (displayed).

> Note in this context
> that `select-frame-set-input-focus' always raises the frame.

Looks unnecessary.  Emacs also calls XSetInputFocus together with
x_ewmh_activate_frame in Fx_focus_frame.  One of those is probably
unnecessary.  x_ewmh_activate_frame tells the WM to try to focus the
frame, but some WMs will also raise the window at the same time.

>> ?  N  Metacity   follow-mouse (mouse)
>> ?  N  Metacity   follow-mouse (sloppy)
>> ?  N  Metacity   click-to-focus (click)
>
> Does Metacity respect `select-frame-set-input-focus' at all?

Yes, this seems to work.  [Though, it also moves the mouse pointer to
the upper right corner of the new frame.  Maybe some Metacity
idiosyncrasy.]

>> Y  N  KWin       follow-mouse
>> Y  N  KWin       click-to-focus
>> Y  M  FluxBox    follow-mouse (Sloppy Focus)
>> Y  M  FluxBox    follow-mouse (Auto Raise)
>
> For the M cases `raise-frame' could move the mouse pointer to that frame
> which seems to call for yet another option.
>
>> Y  N  FluxBox    click-to-focus
>> Y  Y  IceWM      click-to-focus
>
> So IceWM is the only window manager to handle situation B.  IIUC it does
> so because do_switch-frame manages to get Fredirect_frame_focus through
> to redirect input to that frame.  Or do you have another explanation?

It could be, that IceWM gives focus to the other frame because Emacs
called raise-frame (in window--display-buffer-1).  I'm just speculating,
though.  I don't know what Fredirect_frame_focus is used for; but it
looks like something exotic.

> Could you try to GDB do_switch_frame for IceWM and one of the others to
> see they do differently?

I didn't know what to look for.  Below I attach two event traces for 

 emacs -Q --eval '(progn
  (let ((pop-up-frames t))
    (select-frame-set-input-focus
     (window-frame (display-buffer (get-buffer-create "foo")))))
  (let ((display-buffer-reuse-frames t))
    (pop-to-buffer "foo"))
  (sleep-for 1) 
  (kill-emacs))'  2> wm-log

One for Sawfish (with focus-window-when-mapped) and one for IceWM.  I
traced the events in xterm.c:handle_one_xevent and calls to
x_raise_frame.  Maybe you can make some sense out of it.


>> Y  N  Twm        follow-mouse (new frames need mouse click for placement)
>>
>> A and B are the scenarios described above.
>> Y means: Yes, does switch focus.
>> N means: No, doesn't switch focus.
>> ? means: sometimes (probably depending on mouse and window positions)
>> M means: No, doesn't switch focus, except when raising the frame
>>          also moves the mouse pointer into the frame.
>>
>> I set Emacs' focus-follows-mouse according to the WM focus mode (except
>> when I forgot it :-)
>>
>> The Ys for Sawfish are apparently directly related to the
>> focus-window-when-mapped option.  So, it's probably not Emacs that
>> switches the focus in the A scenario, but the window managers.
>
> Can we conclucde that the other window managers implicitly focus a frame
> when mapping it?

The probability is at least not zero :-) 

I guess though, that if the input-hint flag is true, the WM may switch
focus to whatever and whenever it thinks is appropriate (see Metacity).

>> The docstring for select-window could perhaps
>> also state a bit more prominently that the "selected window" and the
>> "input focus" are different things
>
> ... if the implementation is bogus this will hardly help ...
>
>> or at least refer to
>> select-frame-set-input-focus.
>
> That function lumps together too many things.  At least `raise-frame'
> should probably be optional there.
>
>> BTW, below is a proof of concept implementation for the
>> update-focus-lazily idea.
>
> Would this work with `redirect-frame-focus'?  I haven't studied it in
> detail.

I don't know.  It's hard for me to guess for what or when
redirect-frame-focus is used, just by staring at the code.

Helmut.


Lines like the following in the logs means:

xevent: FocusOut serial: 2176 send: 0 win: c00184 mode: NotifyNormal detail: 
NotifyNonlinear

FocusOut is the event type
serial: is the number of last request processed by server 
send: true if this came from a SendEvent request (i.e. by WM)
win: the window id of the event target

and "x_raise_frame: win: c00183 ... done."
is a call to x_raise_frame with argument c00183.

sawfish-log
Description: Sawfish log

icewm-log
Description: IceWM log