bug#44415: 27.1; Child frame loses focus on app switching

[martin rudalics]

> 1. emacs -Q
> 2. Evaluate:
> (select-frame-set-input-focus
>   (make-frame `((parent-frame . ,(selected-frame)))))
> 3. Alt-TAB
> 4. If Emacs is not the only running app Alt-TAB to return to Emacs
>
> Child frame became unfocused.
>
> In GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.22, cairo 
version 1.17.3)
> Windowing system distributor 'The X.Org Foundation', version 11.0.12009000
>
> Same issue on Windows.

IIRC the focus is never given to a child frame in such cases.  A similar
thing happens when you have a child frame focused and you iconify its
parent.  When you deiconify the parent, the child frame loses focus too.

Maybe your problem could be solved under X as follows: According to

https://tronche.com/gui/x/xlib/events/input-focus/normal-and-grabbed.html

When the focus moves from window A to window B, window C is their least
common ancestor, and the pointer is in window P, the X server does the
following:

    If window P is an inferior of window A, it generates a FocusOut
    event on each window from window P up to but not including window A,
    with the detail member of the XFocusOutEvent structure set to
    NotifyPointer.

    It generates a FocusOut event on window A, with the detail member of
    the XFocusOutEvent structure set to NotifyNonlinear.

    It generates a FocusOut event on each window between window A and
    window C, exclusive, with the detail member of each XFocusOutEvent
    structure set to NotifyNonlinearVirtual.

We would first have to check under X whether all of the above really
happen in your case.  If so, we could remember that in some variable.
Hopefully, the third above will cover the case where the pointer is not
in the child frame but the child frame has focus.

Now the next time we get a focus-in event for the parent frame we could
then try to focus the child frame ourselves.  The tricky parts of this
are when and how to flush the above variable and how to disregard it
whenever users click with the mouse into some part of the parent frame
that is not covered by the child frame thus explicitly stating their
wish to focus the parent.

On Windows the situation looks more difficult.  But if WM_KILLFOCUS at
least does name the child frame that loses focus, we could maybe try to
emulate something similar to X.

In either case I can assure you that writing the corresponding code will
be quite tricky and require some understanding of the sequence of events
that may happen when focus changes.  But if you want to give it a try, I
will certainly try to help you.

martin