bug#70046: 29.3; ebuffers mini frame loses focus

bug#70046: 29.3; ebuffers mini frame loses focus

[Vangelis Evangelou]

[-- Attachment #1: Type: text/plain, Size: 3767 bytes --]

When using ebuffers with the default settings, going up and down on
differences by pressing n and p switches focus to the buffers that are
being compared. As an example, run the following commands in terminal:

ping -c 10 example.com > ~/fileA
ping -c 10 example.com > ~/fileB
emacs -Q --eval '(ebuffers (find-file "~/fileA") (find-file "~/fileB"))'

and then press n and p to navigate through the differences. You will notice
that focus switches to the buffers. It doesn't happen always.

In GNU Emacs 29.3 (build 2, x86_64-pc-linux-gnu, X toolkit, cairo
 version 1.16.0, Xaw scroll bars) of 2024-03-25 built on XXX
Windowing system distributor 'The X.Org Foundation', version 11.0.12101004
System Description: Linux Mint 21.3

Configured using:
 'configure --without-pop --without-kerberos --without-kerberos5
 --without-hesiod --without-mail-unlink --without-mailhost
 --with-x-toolkit=lucid --with-file-notification=inotify --with-x
 --with-modules --with-json --with-xft --with-native-compilation=aot'

Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
LCMS2 LIBSELINUX LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG
RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER
WEBP X11 XDBE XIM XPM LUCID ZLIB

Important settings:
  value of $LC_TIME: en_GB.utf8
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util text-property-search time-date mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils comp comp-cstr
warnings icons subr-x rx cl-seq cl-macs gv cl-extra help-mode bytecomp
byte-compile ediff ediff-merg ediff-mult ediff-wind ediff-diff
ediff-help ediff-init cl-loaddefs cl-lib ediff-util rmc iso-transl
tooltip cconv eldoc paren electric uniquify ediff-hook vc-hooks
lisp-float-type elisp-mode mwheel term/x-win x-win term/common-win x-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq
simple cl-generic indonesian philippine cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite emoji-zwj charscript charprop case-table
epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button
loaddefs theme-loaddefs faces cus-face macroexp files window
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget keymap hashtable-print-readable backquote threads dbusbind
inotify lcms2 dynamic-setting system-font-setting font-render-setting
cairo x-toolkit x multi-tty make-network-process native-compile emacs)

Memory information:
((conses 16 89509 8639)
 (symbols 48 7936 0)
 (strings 32 23350 1264)
 (string-bytes 1 698046)
 (vectors 16 17470)
 (vector-slots 8 355883 12474)
 (floats 8 43 52)
 (intervals 56 244 0)
 (buffers 984 15))

[-- Attachment #2: Type: text/html, Size: 4264 bytes --]

bug#70046: 29.3; ebuffers mini frame loses focus

[Eli Zaretskii]

> From: Vangelis Evangelou <evangelou@gmail.com>
> Date: Thu, 28 Mar 2024 08:36:56 +0000
> 
> When using ebuffers with the default settings, going up and down on differences by pressing n and p switches
> focus to the buffers that are being compared. As an example, run the following commands in terminal:
> 
> ping -c 10 example.com > ~/fileA
> ping -c 10 example.com > ~/fileB
> emacs -Q --eval '(ebuffers (find-file "~/fileA") (find-file "~/fileB"))'
> 
> and then press n and p to navigate through the differences. You will notice that focus switches to the buffers.
> It doesn't happen always.

I cannot reproduce this.  I tried many times.

How do you see that focus switches to one of the buffers being
compared?

bug#70046: 29.3; ebuffers mini frame loses focus

[Vangelis Evangelou]

[-- Attachment #1: Type: text/plain, Size: 1147 bytes --]

Because the cursor moves to that buffer and if I press n or p it inserts in
that buffer. Here is a video demonstrating this
https://drive.google.com/file/d/1E7ycJJTYuo62MwViGfiYz_tnornMdXkN/view?usp=sharing

Also, note in the video that the mini frame goes under the top bar. I don't
know if that's an emacs issue though.

On Thu, 28 Mar 2024 at 09:22, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Vangelis Evangelou <evangelou@gmail.com>
> > Date: Thu, 28 Mar 2024 08:36:56 +0000
> >
> > When using ebuffers with the default settings, going up and down on
> differences by pressing n and p switches
> > focus to the buffers that are being compared. As an example, run the
> following commands in terminal:
> >
> > ping -c 10 example.com > ~/fileA
> > ping -c 10 example.com > ~/fileB
> > emacs -Q --eval '(ebuffers (find-file "~/fileA") (find-file "~/fileB"))'
> >
> > and then press n and p to navigate through the differences. You will
> notice that focus switches to the buffers.
> > It doesn't happen always.
>
> I cannot reproduce this.  I tried many times.
>
> How do you see that focus switches to one of the buffers being
> compared?
>

[-- Attachment #2: Type: text/html, Size: 1891 bytes --]

bug#70046: 29.3; ebuffers mini frame loses focus

[Eli Zaretskii]

> From: Vangelis Evangelou <evangelou@gmail.com>
> Date: Thu, 28 Mar 2024 10:08:51 +0000
> Cc: 70046@debbugs.gnu.org
> 
> Because the cursor moves to that buffer and if I press n or p it inserts in that buffer. Here is a video
> demonstrating this
> https://drive.google.com/file/d/1E7ycJJTYuo62MwViGfiYz_tnornMdXkN/view?usp=sharing
> 
> Also, note in the video that the mini frame goes under the top bar. I don't know if that's an emacs issue
> though.

Then I definitely cannot reproduce this.  Could this be because of the
particular window manager you are using and/or your system-wide
settings of the window manager?

bug#70046: 29.3; ebuffers mini frame loses focus

[Vangelis Evangelou]

[-- Attachment #1: Type: text/plain, Size: 1005 bytes --]

Honestly, I don't know. I'm using XFCE, which is not an unusual window
manager. I can try and change some settings if you can suggest to diagnose
the issue. I believe the ebuffers code has changed recently. It used to
work without issues in emacs 27 or 28 (I don't remember which).

On Thu, 28 Mar 2024 at 10:28, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Vangelis Evangelou <evangelou@gmail.com>
> > Date: Thu, 28 Mar 2024 10:08:51 +0000
> > Cc: 70046@debbugs.gnu.org
> >
> > Because the cursor moves to that buffer and if I press n or p it inserts
> in that buffer. Here is a video
> > demonstrating this
> >
> https://drive.google.com/file/d/1E7ycJJTYuo62MwViGfiYz_tnornMdXkN/view?usp=sharing
> >
> > Also, note in the video that the mini frame goes under the top bar. I
> don't know if that's an emacs issue
> > though.
>
> Then I definitely cannot reproduce this.  Could this be because of the
> particular window manager you are using and/or your system-wide
> settings of the window manager?
>

[-- Attachment #2: Type: text/html, Size: 1621 bytes --]

bug#70046: 29.3; ebuffers mini frame loses focus

[Vangelis Evangelou]

[-- Attachment #1: Type: text/plain, Size: 1286 bytes --]

By the way, just to add to that, if I press a or b in the mini frame to
copy the change to the other buffer, then I no longer have the issue of
losing focus after that.

On Thu, 28 Mar 2024 at 10:35, Vangelis Evangelou <evangelou@gmail.com>
wrote:

> Honestly, I don't know. I'm using XFCE, which is not an unusual window
> manager. I can try and change some settings if you can suggest to diagnose
> the issue. I believe the ebuffers code has changed recently. It used to
> work without issues in emacs 27 or 28 (I don't remember which).
>
> On Thu, 28 Mar 2024 at 10:28, Eli Zaretskii <eliz@gnu.org> wrote:
>
>> > From: Vangelis Evangelou <evangelou@gmail.com>
>> > Date: Thu, 28 Mar 2024 10:08:51 +0000
>> > Cc: 70046@debbugs.gnu.org
>> >
>> > Because the cursor moves to that buffer and if I press n or p it
>> inserts in that buffer. Here is a video
>> > demonstrating this
>> >
>> https://drive.google.com/file/d/1E7ycJJTYuo62MwViGfiYz_tnornMdXkN/view?usp=sharing
>> >
>> > Also, note in the video that the mini frame goes under the top bar. I
>> don't know if that's an emacs issue
>> > though.
>>
>> Then I definitely cannot reproduce this.  Could this be because of the
>> particular window manager you are using and/or your system-wide
>> settings of the window manager?
>>
>

[-- Attachment #2: Type: text/html, Size: 2169 bytes --]

bug#70046: 29.3; ebuffers mini frame loses focus

[Eli Zaretskii]

> From: Vangelis Evangelou <evangelou@gmail.com>
> Date: Thu, 28 Mar 2024 10:35:52 +0000
> Cc: 70046@debbugs.gnu.org
> 
> Honestly, I don't know. I'm using XFCE, which is not an unusual window manager. I can try and change some
> settings if you can suggest to diagnose the issue. I believe the ebuffers code has changed recently. It used to
> work without issues in emacs 27 or 28 (I don't remember which).

Maybe Po Lu (CC'ed) could help or have any ideas?

bug#70046: 29.3; ebuffers mini frame loses focus

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Vangelis Evangelou <evangelou@gmail.com> writes:

> Honestly, I don't know. I'm using XFCE, which is not an unusual window
> manager. I can try and change some settings if you can suggest to
> diagnose the issue. I believe the ebuffers code has changed
> recently. It used to work without issues in emacs 27 or 28 (I don't
> remember which).

Would you try building with --with-x-toolkit=no?  I cannot reproduce
this on GNOME, but also can't be certain that this is not a result of my
using a no toolkit build.

bug#70046: 29.3; ebuffers mini frame loses focus

[Vangelis Evangelou]

[-- Attachment #1: Type: text/plain, Size: 702 bytes --]

I tried with --with-x-toolkit=no, and still have this problem.

With emacs 28.2 this is not an issue.


On Thu, 28 Mar 2024 at 12:59, Po Lu <luangruo@yahoo.com> wrote:

> Vangelis Evangelou <evangelou@gmail.com> writes:
>
> > Honestly, I don't know. I'm using XFCE, which is not an unusual window
> > manager. I can try and change some settings if you can suggest to
> > diagnose the issue. I believe the ebuffers code has changed
> > recently. It used to work without issues in emacs 27 or 28 (I don't
> > remember which).
>
> Would you try building with --with-x-toolkit=no?  I cannot reproduce
> this on GNOME, but also can't be certain that this is not a result of my
> using a no toolkit build.
>

[-- Attachment #2: Type: text/html, Size: 1150 bytes --]

bug#70046: 29.3; ebuffers mini frame loses focus

[Vangelis Evangelou]

[-- Attachment #1: Type: text/plain, Size: 1454 bytes --]

Dear all.

I have further information on how to reproduce this bug. I believe this
issue is a combination of emacs version 29.1 and later (the issue is absent
in version 28.1) and my window manager. My window manager is XFCE version
4.18. In the XFCE settings choose "window manager tweaks", then the "focus"
tab and untick the option "activate focus stealing prevention". With this
choice, the issue I mentioned with the miniframe losing focus can be
reproduced. When the "activate focus stealing prevention" option is
selected, then this issue goes away. See settings image here
https://docs.xfce.org/xfce/xfwm4/wmtweaks#focus
I hope this helps.

On Thu, 28 Mar 2024 at 14:27, Vangelis Evangelou <evangelou@gmail.com>
wrote:

> I tried with --with-x-toolkit=no, and still have this problem.
>
> With emacs 28.2 this is not an issue.
>
>
> On Thu, 28 Mar 2024 at 12:59, Po Lu <luangruo@yahoo.com> wrote:
>
>> Vangelis Evangelou <evangelou@gmail.com> writes:
>>
>> > Honestly, I don't know. I'm using XFCE, which is not an unusual window
>> > manager. I can try and change some settings if you can suggest to
>> > diagnose the issue. I believe the ebuffers code has changed
>> > recently. It used to work without issues in emacs 27 or 28 (I don't
>> > remember which).
>>
>> Would you try building with --with-x-toolkit=no?  I cannot reproduce
>> this on GNOME, but also can't be certain that this is not a result of my
>> using a no toolkit build.
>>
>

[-- Attachment #2: Type: text/html, Size: 2324 bytes --]

bug#70046: 29.3; ebuffers mini frame loses focus

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Vangelis Evangelou <evangelou@gmail.com> writes:

> Dear all.
>
> I have further information on how to reproduce this bug. I believe
> this issue is a combination of emacs version 29.1 and later (the issue
> is absent in version 28.1) and my window manager. My window manager is
> XFCE version 4.18. In the XFCE settings choose "window manager
> tweaks", then the "focus" tab and untick the option "activate focus
> stealing prevention". With this choice, the issue I mentioned with the
> miniframe losing focus can be reproduced. When the "activate focus
> stealing prevention" option is selected, then this issue goes
> away. See settings image here
> https://docs.xfce.org/xfce/xfwm4/wmtweaks#focus I hope this helps.

What if you set x-allow-focus-stealing to nil?

bug#70046: 29.3; ebuffers mini frame loses focus

[Vangelis Evangelou]

[-- Attachment #1: Type: text/plain, Size: 1041 bytes --]

I have run emacs like this

emacs -Q --eval '(progn (setq x-allow-focus-stealing nil) (ebuffers
(find-file "~/fileA") (find-file "~/fileB")))'

This does not solve the issue.

On Fri, 5 Apr 2024 at 09:13, Po Lu <luangruo@yahoo.com> wrote:

> Vangelis Evangelou <evangelou@gmail.com> writes:
>
> > Dear all.
> >
> > I have further information on how to reproduce this bug. I believe
> > this issue is a combination of emacs version 29.1 and later (the issue
> > is absent in version 28.1) and my window manager. My window manager is
> > XFCE version 4.18. In the XFCE settings choose "window manager
> > tweaks", then the "focus" tab and untick the option "activate focus
> > stealing prevention". With this choice, the issue I mentioned with the
> > miniframe losing focus can be reproduced. When the "activate focus
> > stealing prevention" option is selected, then this issue goes
> > away. See settings image here
> > https://docs.xfce.org/xfce/xfwm4/wmtweaks#focus I hope this helps.
>
> What if you set x-allow-focus-stealing to nil?
>

[-- Attachment #2: Type: text/html, Size: 1692 bytes --]

bug#70046: 29.3; ebuffers mini frame loses focus

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Vangelis Evangelou <evangelou@gmail.com> writes:

> I have run emacs like this
>
> emacs -Q --eval '(progn (setq x-allow-focus-stealing nil) (ebuffers (find-file "~/fileA") (find-file "~/fileB")))'
>
> This does not solve the issue.

Having debugged this under xfwm4, I've come to the conclusion that this
is the product of two separate bugs in the window manager itself.
Observe the result of running the following code, namely that F1 is
moved above F2 while it continues to possess the input focus:

  (setq f1 (selected-frame)
        f2 (make-frame '((name . "FRAME 2"))))
  (progn
    (raise-frame f2)
    (x-focus-frame f1))

Well-behaved window managers will not focus F2 in response to the call
to `raise-frame', but only raise the frame to the top of the window
stack, leaving the keyboard focus intact, while xfwm4 has adopted a
rather creative interpretation of the meaning of "raise" that holds it
to be synonymous with activating the frame unless "focus stealing
prevention" is enabled.  By itself, this is not sufficient to trigger
your problem, but when windows so acquire the input focus, the new focus
state is not registered by the window manager, with the result that
subsequent requests to activate (i.e. transfer the input focus) to the
previously selected window are disregarded to the extent that they
affect the keyboard focus:

TRACE[events.c:1334] handleConfigureRequest(): window "FRAME 2" (0x40035c)
TRACE[client.c:561] clientAdjustCoordGravity(): client "FRAME 2" (0x40035c)
TRACE[client.c:907] clientMoveResizeWindow(): client "FRAME 2" (0x40035c)
TRACE[display.c:767] myDisplayGetCurrentTime(): timestamp=1371435444
TRACE[hints.c:1305] getXServerTime(): timestamp=1371435444
TRACE[client.c:2595] clientActivate(): client "FRAME 2" (0x40035c)
TRACE[transients.c:336] clientGetTransientFor(): client "FRAME 2" (0x40035c)
TRACE[transients.c:54] clientIsDirectTransient(): client "FRAME 2" (0x40035c)
TRACE[transients.c:54] clientIsDirectTransient(): client "FRAME 2" (0x40035c)
TRACE[stacking.c:537] clientAdjustFullscreenLayer(): unsetting fullscreen layer for  "test.el" (0x40013c)
TRACE[client.c:2374] clientShow(): client "FRAME 2" (0x40035c)
TRACE[transients.c:429] clientListTransientOrModal(): client "FRAME 2" (0x40035c)
TRACE[transients.c:227] clientIsTransientOrModalFor(): client 1 "test.el" (0x40013c), client 2 "FRAME 2" (0x40035c)
TRACE[transients.c:177] clientIsTransientFor(): client 1 "test.el" (0x40013c), client 2 "FRAME 2" (0x40035c)
TRACE[transients.c:205] clientIsModalFor(): client 1 "test.el" (0x40013c), client 2 "FRAME 2" (0x40035c)
TRACE[transients.c:227] clientIsTransientOrModalFor(): client 1 "test.el" (0x40013c), client 2 "FRAME 2" (0x40035c)
TRACE[transients.c:177] clientIsTransientFor(): client 1 "test.el" (0x40013c), client 2 "FRAME 2" (0x40035c)
TRACE[transients.c:205] clientIsModalFor(): client 1 "test.el" (0x40013c), client 2 "FRAME 2" (0x40035c)
TRACE[client.c:2254] clientSetWorkspaceSingle(): client "FRAME 2" (0x40035c)
TRACE[stacking.c:370] clientRaise(): client "FRAME 2" (0x40035c) above (0x0)
TRACE[stacking.c:176] clientGetNextTopMost(): layer 4
TRACE[stacking.c:182] clientGetNextTopMost(): *** stack window "FRAME 2" (0x40035c), layer 4
TRACE[stacking.c:182] clientGetNextTopMost(): *** stack window "test.el" (0x40013c), layer 4
TRACE[transients.c:336] clientGetTransientFor(): client "FRAME 2" (0x40035c)
TRACE[transients.c:54] clientIsDirectTransient(): client "FRAME 2" (0x40035c)
TRACE[transients.c:54] clientIsDirectTransient(): client "FRAME 2" (0x40035c)
TRACE[transients.c:227] clientIsTransientOrModalFor(): client 1 "test.el" (0x40013c), client 2 "FRAME 2" (0x40035c)
TRACE[transients.c:177] clientIsTransientFor(): client 1 "test.el" (0x40013c), client 2 "FRAME 2" (0x40035c)
TRACE[transients.c:205] clientIsModalFor(): client 1 "test.el" (0x40013c), client 2 "FRAME 2" (0x40035c)
DBG[stacking.c:52] clientApplyStackList(): applying stack list
DBG[stacking.c:71] clientApplyStackList():   [5] "FRAME 2" (0x40035c)
DBG[stacking.c:71] clientApplyStackList():   [6] "test.el" (0x40013c)
TRACE[netwm.c:966] clientSetNetClientList(): entering
TRACE[netwm.c:978] clientSetNetClientList(): 2 windows in list for 2 clients
TRACE[focus.c:547] clientSetFocus(): entering
TRACE[transients.c:309] clientGetModalFor(): client "FRAME 2" (0x40035c)
TRACE[transients.c:205] clientIsModalFor(): client 1 "test.el" (0x40013c), client 2 "FRAME 2" (0x40035c)
TRACE[focus.c:562] clientSetFocus(): setting focus to client "FRAME 2" (0x40035c) with timestamp 1371435444
TRACE[focus.c:386] clientAcceptFocus(): client "FRAME 2" (0x40035c)
TRACE[client.c:734] clientConfigure(): client "FRAME 2" (0x40035c) not contrained, type 1
TRACE[client.c:777] clientConfigure(): above
TRACE[stacking.c:370] clientRaise(): client "FRAME 2" (0x40035c) above (0x0)
TRACE[stacking.c:382] clientRaise(): client "FRAME 2" (0x40035c) already raised
DBG[client.c:705] clientSendConfigureNotify(): Sending ConfigureNotify
TRACE[compositor.c:4544] compositorHandleEvent(): event type 23
TRACE[events.c:2303] xfwm4_event_filter(): leaving
TRACE[event_filter.c:117] default_event_filter(): unhandled ConfigureRequest event
TRACE[events.c:2301] xfwm4_event_filter(): entering
TRACE[events.c:2170] handleEvent(): entering
TRACE[events.c:1892] handleClientMessage(): window (0x40013c)
TRACE[client.c:2201] clientGetFromWindow(): client "test.el" (0x40013c)
TRACE[client.c:2207] clientGetFromWindow(): found "test.el" (mode WINDOW)
TRACE[events.c:1940] handleClientMessage(): client "test.el" (0x40013c) has received a NET_ACTIVE_WINDOW event
TRACE[netwm.c:1440] clientHandleNetActiveWindow(): client "test.el" (0x40013c)
TRACE[display.c:782] myDisplayGetTime(): timestamp=1371435444
TRACE[display.c:791] myDisplayGetLastUserTime(): timestamp=1371435444
TRACE[netwm.c:1454] clientHandleNetActiveWindow(): time of event received is 1371435444, current XServer time is 1371435444
TRACE[client.c:2595] clientActivate(): client "test.el" (0x40013c)
TRACE[transients.c:336] clientGetTransientFor(): client "test.el" (0x40013c)
TRACE[transients.c:54] clientIsDirectTransient(): client "test.el" (0x40013c)
TRACE[transients.c:54] clientIsDirectTransient(): client "test.el" (0x40013c)
TRACE[client.c:2374] clientShow(): client "test.el" (0x40013c)
TRACE[transients.c:429] clientListTransientOrModal(): client "test.el" (0x40013c)
TRACE[transients.c:227] clientIsTransientOrModalFor(): client 1 "FRAME 2" (0x40035c), client 2 "test.el" (0x40013c)
TRACE[transients.c:177] clientIsTransientFor(): client 1 "FRAME 2" (0x40035c), client 2 "test.el" (0x40013c)
TRACE[transients.c:205] clientIsModalFor(): client 1 "FRAME 2" (0x40035c), client 2 "test.el" (0x40013c)
TRACE[transients.c:227] clientIsTransientOrModalFor(): client 1 "FRAME 2" (0x40035c), client 2 "test.el" (0x40013c)
TRACE[transients.c:177] clientIsTransientFor(): client 1 "FRAME 2" (0x40035c), client 2 "test.el" (0x40013c)
TRACE[transients.c:205] clientIsModalFor(): client 1 "FRAME 2" (0x40035c), client 2 "test.el" (0x40013c)
TRACE[client.c:2254] clientSetWorkspaceSingle(): client "test.el" (0x40013c)
TRACE[stacking.c:370] clientRaise(): client "test.el" (0x40013c) above (0x0)
TRACE[stacking.c:176] clientGetNextTopMost(): layer 4
TRACE[stacking.c:182] clientGetNextTopMost(): *** stack window "test.el" (0x40013c), layer 4
TRACE[stacking.c:182] clientGetNextTopMost(): *** stack window "FRAME 2" (0x40035c), layer 4
TRACE[transients.c:336] clientGetTransientFor(): client "test.el" (0x40013c)
TRACE[transients.c:54] clientIsDirectTransient(): client "test.el" (0x40013c)
TRACE[transients.c:54] clientIsDirectTransient(): client "test.el" (0x40013c)
TRACE[transients.c:227] clientIsTransientOrModalFor(): client 1 "FRAME 2" (0x40035c), client 2 "test.el" (0x40013c)
TRACE[transients.c:177] clientIsTransientFor(): client 1 "FRAME 2" (0x40035c), client 2 "test.el" (0x40013c)
TRACE[transients.c:205] clientIsModalFor(): client 1 "FRAME 2" (0x40035c), client 2 "test.el" (0x40013c)
DBG[stacking.c:52] clientApplyStackList(): applying stack list
DBG[stacking.c:71] clientApplyStackList():   [5] "test.el" (0x40013c)
DBG[stacking.c:71] clientApplyStackList():   [6] "FRAME 2" (0x40035c)
TRACE[netwm.c:966] clientSetNetClientList(): entering
TRACE[netwm.c:978] clientSetNetClientList(): 2 windows in list for 2 clients
TRACE[focus.c:547] clientSetFocus(): entering
TRACE[transients.c:309] clientGetModalFor(): client "test.el" (0x40013c)
TRACE[transients.c:205] clientIsModalFor(): client 1 "FRAME 2" (0x40035c), client 2 "test.el" (0x40013c)
TRACE[focus.c:562] clientSetFocus(): setting focus to client "test.el" (0x40013c) with timestamp 1371435444
TRACE[focus.c:572] clientSetFocus(): client "test.el" (0x40013c) is already focused, ignoring request

and in consequence this portion of ediff-recenter:

      (progn
	(if (window-live-p ediff-window-A)
	    (raise-frame (window-frame ediff-window-A)))
	(if (window-live-p ediff-window-B)
	    (raise-frame (window-frame ediff-window-B)))
	(if (window-live-p ediff-window-C)
	    (raise-frame (window-frame ediff-window-C)))))
  (if (and (display-graphic-p)
	   (frame-live-p ediff-control-frame)
	   (not ediff-use-long-help-message)
	   (not (ediff-frame-iconified-p ediff-control-frame)))
      (if (fboundp 'select-frame-set-input-focus)
	  (select-frame-set-input-focus ediff-control-frame)
	(raise-frame ediff-control-frame)
	(select-frame ediff-control-frame)))

whose purpose is to preserve the position of the ediff control frame
relative to the remainder instead prompts the window manager to transfer
the input focus to a diff-displaying frame, before being left with no
means of restoring the input focus to its original owner.  It is also
reproducible consistently with Emacs 28.1, so I suggest reporting this
issue to the xfwm developers; closing.