bug#61337: 29.0.60; Setting frame-title-format makes Emacs to steal focus

bug#61337: 29.0.60; Setting frame-title-format makes Emacs to steal focus

[Oscar Fuentes]

This is on KDE with two desktops.

Let's suppose that we are on Desktop1. On xterm, for instance:

$ emacs -Q

Eval this on *scratch*:

(setq frame-title-format "hello")

Click somewhere on Emacs' frame to update its displayed title.

Set focus to xterm, switch to Desktop2 and back to Desktop1. Focus is on
Emacs' frame. The z-order is not altered.

After bisecting:

commit e99f41f03a97641ee05ba4a27f8b91c190f55df1
Author: Po Lu <luangruo@yahoo.com>
Date:   Thu Jun 9 21:48:19 2022 +0800

    Fix recalculation of `icon-title-format' after a frame is iconified
    
    Previously it would only happen upon the next mode line
    redisplay, meaning that just pressing C-z would not update the
    implicit title, since C-z doesn't cause a redisplay.
    
    * src/dispextern.h: Update prototypes.
    * src/frame.h (SET_FRAME_ICONIFIED): De-slugify.  Call
    `gui_consider_frame_title', since `icon-title-format' might be
    different from the current frame title.
    * src/xdisp.c (gui_consider_frame_title): Export (also in
    dispextern.h).  (bug#55850)

I checked that reverting this commit fixes the problem.


In GNU Emacs 29.0.60 (build 3, x86_64-pc-linux-gnu, X toolkit, cairo
 version 1.16.0) of 2023-02-07 built on sky
Repository revision: 746748f5c283b98a221571e725833affe304a748
Repository branch: emacs-29
Windowing system distributor 'The X.Org Foundation', version 11.0.12101006
System Description: Debian GNU/Linux bookworm/sid

Configured using:
 'configure --without-toolkit-scroll-bars --with-x-toolkit=lucid
 --with-modules --without-imagemagick'

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

Important settings:
  value of $LANG: es_ES.UTF-8
  locale-coding-system: utf-8-unix

bug#61337: 29.0.60; Setting frame-title-format makes Emacs to steal focus

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

"Oscar Fuentes" <ofv@wanadoo.es> writes:

> This is on KDE with two desktops.
>
> Let's suppose that we are on Desktop1. On xterm, for instance:
>
> $ emacs -Q
>
> Eval this on *scratch*:
>
> (setq frame-title-format "hello")
>
> Click somewhere on Emacs' frame to update its displayed title.
>
> Set focus to xterm, switch to Desktop2 and back to Desktop1. Focus is on
> Emacs' frame. The z-order is not altered.
>
> After bisecting:
>
> commit e99f41f03a97641ee05ba4a27f8b91c190f55df1
> Author: Po Lu <luangruo@yahoo.com>
> Date:   Thu Jun 9 21:48:19 2022 +0800
>
>     Fix recalculation of `icon-title-format' after a frame is iconified
>     
>     Previously it would only happen upon the next mode line
>     redisplay, meaning that just pressing C-z would not update the
>     implicit title, since C-z doesn't cause a redisplay.
>     
>     * src/dispextern.h: Update prototypes.
>     * src/frame.h (SET_FRAME_ICONIFIED): De-slugify.  Call
>     `gui_consider_frame_title', since `icon-title-format' might be
>     different from the current frame title.
>     * src/xdisp.c (gui_consider_frame_title): Export (also in
>     dispextern.h).  (bug#55850)
>
> I checked that reverting this commit fixes the problem.
>
>
> In GNU Emacs 29.0.60 (build 3, x86_64-pc-linux-gnu, X toolkit, cairo
>  version 1.16.0) of 2023-02-07 built on sky
> Repository revision: 746748f5c283b98a221571e725833affe304a748
> Repository branch: emacs-29
> Windowing system distributor 'The X.Org Foundation', version 11.0.12101006
> System Description: Debian GNU/Linux bookworm/sid
>
> Configured using:
>  'configure --without-toolkit-scroll-bars --with-x-toolkit=lucid
>  --with-modules --without-imagemagick'
>
> Configured features:
> CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
> LIBOTF LIBSELINUX LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PNG RSVG
> SECCOMP SOUND THREADS TIFF TREE_SITTER WEBP X11 XAW3D XDBE XIM XINPUT2
> XPM LUCID ZLIB
>
> Important settings:
>   value of $LANG: es_ES.UTF-8
>   locale-coding-system: utf-8-unix

Thanks.  Does this solve the problem?

diff --git a/src/xfns.c b/src/xfns.c
index 3a129211463..b64ebd0aefd 100644
--- a/src/xfns.c
+++ b/src/xfns.c
@@ -2329,7 +2329,7 @@ x_set_title (struct frame *f, Lisp_Object name, Lisp_Object old_name)
   else
     CHECK_STRING (name);
 
-  x_set_name_internal (f, name);
+  x_set_name (f, arg, false);
 }
 
 void

bug#61337: 29.0.60; Setting frame-title-format makes Emacs to steal focus

[Óscar Fuentes]

Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs@gnu.org> writes:

> Thanks.  Does this solve the problem?
>
> diff --git a/src/xfns.c b/src/xfns.c
> index 3a129211463..b64ebd0aefd 100644
> --- a/src/xfns.c
> +++ b/src/xfns.c
> @@ -2329,7 +2329,7 @@ x_set_title (struct frame *f, Lisp_Object name, Lisp_Object old_name)
>    else
>      CHECK_STRING (name);
>  
> -  x_set_name_internal (f, name);
> +  x_set_name (f, arg, false);

I replaced `arg' with `name'.

>  }


The problem persists.

bug#61337: 29.0.60; Setting frame-title-format makes Emacs to steal focus

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

Óscar Fuentes <ofv@wanadoo.es> writes:

> Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text
> editors" <bug-gnu-emacs@gnu.org> writes:
>
>> Thanks.  Does this solve the problem?
>>
>> diff --git a/src/xfns.c b/src/xfns.c
>> index 3a129211463..b64ebd0aefd 100644
>> --- a/src/xfns.c
>> +++ b/src/xfns.c
>> @@ -2329,7 +2329,7 @@ x_set_title (struct frame *f, Lisp_Object name, Lisp_Object old_name)
>>    else
>>      CHECK_STRING (name);
>>  
>> -  x_set_name_internal (f, name);
>> +  x_set_name (f, arg, false);
>
> I replaced `arg' with `name'.
>
>>  }
>
>
> The problem persists.

Hmm.  What if you comment out the call to

  x_set_name_internal (f, name);

entirely?

bug#61337: 29.0.60; Setting frame-title-format makes Emacs to steal focus

[Óscar Fuentes]

Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs@gnu.org> writes:

> Hmm.  What if you comment out the call to
>
>   x_set_name_internal (f, name);
>
> entirely?

Emacs keeps stealing the focus.

bug#61337: 29.0.60; Setting frame-title-format makes Emacs to steal focus

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

Óscar Fuentes <ofv@wanadoo.es> writes:

> Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text
> editors" <bug-gnu-emacs@gnu.org> writes:
>
>> Hmm.  What if you comment out the call to
>>
>>   x_set_name_internal (f, name);
>>
>> entirely?
>
> Emacs keeps stealing the focus.

What if you do this?

My suspicion is that the icon name is now being set to reflect that the
frame has been iconified, and KWin (wrongly) treats that as an attempt
to focus the frame.

diff --git a/src/xterm.c b/src/xterm.c
index 1325d923be9..fcac6bc044f 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -25584,6 +25584,8 @@ x_text_icon (struct frame *f, const char *icon_name)
   if (FRAME_X_WINDOW (f) == 0)
     return true;
 
+  return;
+
   {
     XTextProperty text;
     text.value = (unsigned char *) icon_name;

bug#61337: 29.0.60; Setting frame-title-format makes Emacs to steal focus

[Óscar Fuentes]

Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs@gnu.org> writes:

> What if you do this?
>
> My suspicion is that the icon name is now being set to reflect that the
> frame has been iconified, and KWin (wrongly) treats that as an attempt
> to focus the frame.
>
> diff --git a/src/xterm.c b/src/xterm.c
> index 1325d923be9..fcac6bc044f 100644
> --- a/src/xterm.c
> +++ b/src/xterm.c
> @@ -25584,6 +25584,8 @@ x_text_icon (struct frame *f, const char *icon_name)
>    if (FRAME_X_WINDOW (f) == 0)
>      return true;
>  
> +  return;
> +
>    {
>      XTextProperty text;
>      text.value = (unsigned char *) icon_name;

Same. GCC warned about missing return value, so then I tried `false' and
finally `true'. No change.

bug#61337: 29.0.60; Setting frame-title-format makes Emacs to steal focus

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

Óscar Fuentes <ofv@wanadoo.es> writes:

> Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text
> editors" <bug-gnu-emacs@gnu.org> writes:
>
>> What if you do this?
>>
>> My suspicion is that the icon name is now being set to reflect that the
>> frame has been iconified, and KWin (wrongly) treats that as an attempt
>> to focus the frame.
>>
>> diff --git a/src/xterm.c b/src/xterm.c
>> index 1325d923be9..fcac6bc044f 100644
>> --- a/src/xterm.c
>> +++ b/src/xterm.c
>> @@ -25584,6 +25584,8 @@ x_text_icon (struct frame *f, const char *icon_name)
>>    if (FRAME_X_WINDOW (f) == 0)
>>      return true;
>>  
>> +  return;
>> +
>>    {
>>      XTextProperty text;
>>      text.value = (unsigned char *) icon_name;
>
> Same. GCC warned about missing return value, so then I tried `false' and
> finally `true'. No change.

Would you please run:

  xprop -spy

in a separate terminal emulator window, click on the Emacs frame, switch
to xterm, the other desktop, and back again, and then tell me what xprop
prints?

Thank you.

bug#61337: 29.0.60; Setting frame-title-format makes Emacs to steal focus

[Óscar Fuentes]

Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs@gnu.org> writes:

> Would you please run:
>
>   xprop -spy
>
> in a separate terminal emulator window, click on the Emacs frame, switch
> to xterm, the other desktop, and back again, and then tell me what xprop
> prints?
>
> Thank you.

Here it goes... Please note that I had to click twice on Emacs' window
to focus it, because after starting xprop the mouse cursor was a
cross-hair and clicking the first time on Emacs did not focus it,
although it generated a bunch of output on xprop's terminal.

~/dev/emacs/emacs$ xprop -spy
_NET_WM_ICON_GEOMETRY(CARDINAL) = 870, 1036, 275, 44
_MOTIF_DRAG_RECEIVER_INFO(_MOTIF_DRAG_RECEIVER_INFO) = 0x6c, 0x0, 0x5, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0
XdndAware(ATOM) = BITMAP
_NET_WM_USER_TIME(CARDINAL) = 132529067
_NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_MOVE, _NET_WM_ACTION_RESIZE, _NET_WM_ACTION_MINIMIZE, _NET_WM_ACTION_SHADE, _NET_WM_ACTION_MAXIMIZE_VERT, _NET_WM_ACTION_MAXIMIZE_HORZ, _NET_WM_ACTION_FULLSCREEN, _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_CLOSE
_KDE_NET_WM_FRAME_STRUT(CARDINAL) = 0, 0, 29, 0
_NET_FRAME_EXTENTS(CARDINAL) = 0, 0, 29, 0
_NET_WM_DESKTOP(CARDINAL) = 0
WM_STATE(WM_STATE):
                window state: Normal
                icon window: 0x0
_NET_WM_STATE(ATOM) = 
_KDE_NET_WM_ACTIVITIES(STRING) = "3c05b29d-0043-47f1-b537-76640c25eaa2"
_NET_WM_SYNC_FENCES(CARDINAL) = 65011929, 65011930
_NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 65011928
_NET_WM_PID(CARDINAL) = 519276
_NET_WM_ICON_NAME(UTF8_STRING) = "Emacs: *scratch* --  @ sky"
_NET_WM_NAME(UTF8_STRING) = "Emacs: *scratch* --  @ sky"
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, WM_TAKE_FOCUS, WM_SAVE_YOURSELF, _NET_WM_PING, _NET_WM_SYNC_REQUEST
_KDE_NET_WM_USER_CREATION_TIME(CARDINAL) = 129597836
WM_CLIENT_LEADER(WINDOW): window id # 0x3e00014
WM_LOCALE_NAME(STRING) = "es_ES.UTF-8"
WM_CLASS(STRING) = "emacs", "Emacs"
WM_HINTS(WM_HINTS):
                Client accepts input or input focus: True
                Initial state is Normal State.
                bitmap id # to use for icon: 0x3e000c3
                bitmap id # of mask for icon: 0x3e000c5
WM_NORMAL_HINTS(WM_SIZE_HINTS):
                user specified size: 920 by 859
                program specified minimum size: 28 by 2
                program specified resize increment: 11 by 23
                program specified base size: 28 by 2
                window gravity: NorthWest
WM_CLIENT_MACHINE(STRING) = "sky"
WM_ICON_NAME(STRING) = "Emacs: *scratch* --  @ sky"
WM_NAME(STRING) = "Emacs: *scratch* --  @ sky"
_NET_WM_USER_TIME(CARDINAL) = 132535817
_NET_WM_STATE(ATOM) = _NET_WM_STATE_FOCUSED
_NET_WM_STATE(ATOM) = 
_NET_WM_STATE(ATOM) = 
WM_STATE(WM_STATE):
                window state: Iconic
                icon window: 0x0
WM_NAME(STRING) = "*scratch* - GNU Emacs at sky"
_NET_WM_NAME(UTF8_STRING) = "*scratch* - GNU Emacs at sky"
WM_ICON_NAME(STRING) = "*scratch* - GNU Emacs at sky"
_NET_WM_ICON_NAME(UTF8_STRING) = "*scratch* - GNU Emacs at sky"
_NET_WM_STATE(ATOM) = 
WM_NAME(STRING) = "Emacs: *scratch* --  @ sky"
_NET_WM_NAME(UTF8_STRING) = "Emacs: *scratch* --  @ sky"
WM_ICON_NAME(STRING) = "Emacs: *scratch* --  @ sky"
_NET_WM_ICON_NAME(UTF8_STRING) = "Emacs: *scratch* --  @ sky"
_NET_WM_STATE(ATOM) = 
_NET_WM_STATE(ATOM) = 
WM_STATE(WM_STATE):
                window state: Normal
                icon window: 0x0
_NET_WM_USER_TIME(CARDINAL) = 132540735
_NET_WM_STATE(ATOM) = _NET_WM_STATE_FOCUSED
_NET_WM_STATE(ATOM) = 
^C
~/dev/emacs/emacs$ 

bug#61337: 29.0.60; Setting frame-title-format makes Emacs to steal focus

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

Óscar Fuentes <ofv@wanadoo.es> writes:

> WM_STATE(WM_STATE):
>                 window state: Iconic
>                 icon window: 0x0
> WM_NAME(STRING) = "*scratch* - GNU Emacs at sky"
> _NET_WM_NAME(UTF8_STRING) = "*scratch* - GNU Emacs at sky"
> WM_ICON_NAME(STRING) = "*scratch* - GNU Emacs at sky"
> _NET_WM_ICON_NAME(UTF8_STRING) = "*scratch* - GNU Emacs at sky"
> _NET_WM_STATE(ATOM) = 
> WM_NAME(STRING) = "Emacs: *scratch* --  @ sky"
> _NET_WM_NAME(UTF8_STRING) = "Emacs: *scratch* --  @ sky"
> WM_ICON_NAME(STRING) = "Emacs: *scratch* --  @ sky"
> _NET_WM_ICON_NAME(UTF8_STRING) = "Emacs: *scratch* --  @ sky"
> _NET_WM_STATE(ATOM) = 
> _NET_WM_STATE(ATOM) = 
> WM_STATE(WM_STATE):
>                 window state: Normal
>                 icon window: 0x0
> _NET_WM_USER_TIME(CARDINAL) = 132540735
> _NET_WM_STATE(ATOM) = _NET_WM_STATE_FOCUSED
> _NET_WM_STATE(ATOM) = 
> ^C
> ~/dev/emacs/emacs$ 

I think I see the problem here: after moving to a different workspace,
the window manager told Emacs that the frame was iconified (this is what
most window managers report to windows in a different desktop), and as a
result the icon and window manager names were changed to reflect
`icon-title-format'.

KWin seems to treat this as Emacs asking to be focused.

If you set `icon-title-format' to the same as `frame-title-format', and
in addition apply this patch:

diff --git a/src/xfns.c b/src/xfns.c
index 3a129211463..7f1128399a8 100644
--- a/src/xfns.c
+++ b/src/xfns.c
@@ -2317,7 +2317,7 @@ x_implicitly_set_name (struct frame *f, Lisp_Object arg, Lisp_Object oldval)
 x_set_title (struct frame *f, Lisp_Object name, Lisp_Object old_name)
 {
   /* Don't change the title if it's already NAME.  */
-  if (EQ (name, f->title))
+  if (Fstring_equal (name, f->title))
     return;
 
   update_mode_lines = 38;

does the problem go away?

Thanks.

bug#61337: 29.0.60; Setting frame-title-format makes Emacs to steal focus

[Óscar Fuentes]

Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs@gnu.org> writes:

> If you set `icon-title-format' to the same as `frame-title-format', and
> in addition apply this patch:
>
> diff --git a/src/xfns.c b/src/xfns.c
> index 3a129211463..7f1128399a8 100644
> --- a/src/xfns.c
> +++ b/src/xfns.c
> @@ -2317,7 +2317,7 @@ x_implicitly_set_name (struct frame *f, Lisp_Object arg, Lisp_Object oldval)
>  x_set_title (struct frame *f, Lisp_Object name, Lisp_Object old_name)
>  {
>    /* Don't change the title if it's already NAME.  */
> -  if (EQ (name, f->title))
> +  if (Fstring_equal (name, f->title))
>      return;
>  
>    update_mode_lines = 38;
>
> does the problem go away?

Yes!

bug#61337: 29.0.60; Setting frame-title-format makes Emacs to steal focus

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

Óscar Fuentes <ofv@wanadoo.es> writes:

> Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text
> editors" <bug-gnu-emacs@gnu.org> writes:
>
>> If you set `icon-title-format' to the same as `frame-title-format', and
>> in addition apply this patch:
>>
>> diff --git a/src/xfns.c b/src/xfns.c
>> index 3a129211463..7f1128399a8 100644
>> --- a/src/xfns.c
>> +++ b/src/xfns.c
>> @@ -2317,7 +2317,7 @@ x_implicitly_set_name (struct frame *f, Lisp_Object arg, Lisp_Object oldval)
>>  x_set_title (struct frame *f, Lisp_Object name, Lisp_Object old_name)
>>  {
>>    /* Don't change the title if it's already NAME.  */
>> -  if (EQ (name, f->title))
>> +  if (Fstring_equal (name, f->title))
>>      return;
>>  
>>    update_mode_lines = 38;
>>
>> does the problem go away?
>
> Yes!

Thanks.

Anyone know if this is ok for Emacs 29?

bug#61337: 29.0.60; Setting frame-title-format makes Emacs to steal focus

[Eli Zaretskii]

> Cc: 61337@debbugs.gnu.org
> Date: Thu, 09 Feb 2023 16:15:39 +0800
> From:  Po Lu via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> Óscar Fuentes <ofv@wanadoo.es> writes:
> 
> > Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text
> > editors" <bug-gnu-emacs@gnu.org> writes:
> >
> >> If you set `icon-title-format' to the same as `frame-title-format', and
> >> in addition apply this patch:
> >>
> >> diff --git a/src/xfns.c b/src/xfns.c
> >> index 3a129211463..7f1128399a8 100644
> >> --- a/src/xfns.c
> >> +++ b/src/xfns.c
> >> @@ -2317,7 +2317,7 @@ x_implicitly_set_name (struct frame *f, Lisp_Object arg, Lisp_Object oldval)
> >>  x_set_title (struct frame *f, Lisp_Object name, Lisp_Object old_name)
> >>  {
> >>    /* Don't change the title if it's already NAME.  */
> >> -  if (EQ (name, f->title))
> >> +  if (Fstring_equal (name, f->title))
> >>      return;
> >>  
> >>    update_mode_lines = 38;
> >>
> >> does the problem go away?
> >
> > Yes!
> 
> Thanks.
> 
> Anyone know if this is ok for Emacs 29?

Which part? the change in xfns.c is fine (it just makes the code
slower, so perhaps test EQ first and Fstring_equal if EQ doesn't
return non-zero), but if someone sets icon-title-format in a way that
produces a different string from what frame-title-format does, it will
not work.  And forcing these two formats to produce the same strings
is definitely NOT okay, not for emacs-29, not ever.

However, to tell the truth, I don't really understand the phenomenon
being complained about in this case.  The original report says: "the
z-order is not altered", whereas the conclusion of the analysis is
"KWin seems to treat this as Emacs asking to be focused".  Would you
please describe the problem in easier-to-understand terms and use the
user-facing behavior instead of technical terms like z-order, so that
I could at least make up my mind whether this issue is serious, and
perhaps think about alternative solutions?  E.g., I don't yet
understand why returning early in x_set_title should help here, and
how.

Thanks.

bug#61337: 29.0.60; Setting frame-title-format makes Emacs to steal focus

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

Eli Zaretskii <eliz@gnu.org> writes:

> Which part? the change in xfns.c is fine (it just makes the code
> slower, so perhaps test EQ first and Fstring_equal if EQ doesn't
> return non-zero)

Just the change in xfns.c.  It fixes a bug in the original code (which
was trying to test whether or not both strings were equal, but didn't
handle the case where the strings were equal, but not EQ.)

>, but if someone sets icon-title-format in a way that
> produces a different string from what frame-title-format does, it will
> not work.  And forcing these two formats to produce the same strings
> is definitely NOT okay, not for emacs-29, not ever.

That isn't the change here.

> However, to tell the truth, I don't really understand the phenomenon
> being complained about in this case.  The original report says: "the
> z-order is not altered", whereas the conclusion of the analysis is
> "KWin seems to treat this as Emacs asking to be focused".  Would you
> please describe the problem in easier-to-understand terms and use the
> user-facing behavior instead of technical terms like z-order, so that
> I could at least make up my mind whether this issue is serious, and
> perhaps think about alternative solutions?  E.g., I don't yet
> understand why returning early in x_set_title should help here, and
> how.

The problem is that KWin apparently focuses a window if its title
changes while it is in a different workspace.  That's misbehavior on
KWin's part, and likely a bug.

Since moving to a different desktop is a form of iconification under X,
Emacs switches to displaying the icon title.

The change to xfns.c prevents Emacs from changing the title if the icon
title is identical to the frame title, which should make it possible to
work around the problem by setting icon-title-format to the same text as
frame-title-format; the rest is something that can only be fixed by its
developers.

The problem does not exist in Emacs 28, because icon-title-format did
not work there at all.

Thanks.

bug#61337: 29.0.60; Setting frame-title-format makes Emacs to steal focus

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: ofv@wanadoo.es,  61337@debbugs.gnu.org
> Date: Thu, 09 Feb 2023 18:23:00 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Which part? the change in xfns.c is fine (it just makes the code
> > slower, so perhaps test EQ first and Fstring_equal if EQ doesn't
> > return non-zero)
> 
> Just the change in xfns.c.  It fixes a bug in the original code (which
> was trying to test whether or not both strings were equal, but didn't
> handle the case where the strings were equal, but not EQ.)

This part of the change is OK for emacs-29.

> > However, to tell the truth, I don't really understand the phenomenon
> > being complained about in this case.  The original report says: "the
> > z-order is not altered", whereas the conclusion of the analysis is
> > "KWin seems to treat this as Emacs asking to be focused".  Would you
> > please describe the problem in easier-to-understand terms and use the
> > user-facing behavior instead of technical terms like z-order, so that
> > I could at least make up my mind whether this issue is serious, and
> > perhaps think about alternative solutions?  E.g., I don't yet
> > understand why returning early in x_set_title should help here, and
> > how.
> 
> The problem is that KWin apparently focuses a window if its title
> changes while it is in a different workspace.  That's misbehavior on
> KWin's part, and likely a bug.

How is this related to "the z-order isn't change" problem which Óscar
complained about?

bug#61337: 29.0.60; Setting frame-title-format makes Emacs to steal focus

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

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Po Lu <luangruo@yahoo.com>
>> Cc: ofv@wanadoo.es,  61337@debbugs.gnu.org
>> Date: Thu, 09 Feb 2023 18:23:00 +0800
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > Which part? the change in xfns.c is fine (it just makes the code
>> > slower, so perhaps test EQ first and Fstring_equal if EQ doesn't
>> > return non-zero)
>> 
>> Just the change in xfns.c.  It fixes a bug in the original code (which
>> was trying to test whether or not both strings were equal, but didn't
>> handle the case where the strings were equal, but not EQ.)
>
> This part of the change is OK for emacs-29.
>
>> > However, to tell the truth, I don't really understand the phenomenon
>> > being complained about in this case.  The original report says: "the
>> > z-order is not altered", whereas the conclusion of the analysis is
>> > "KWin seems to treat this as Emacs asking to be focused".  Would you
>> > please describe the problem in easier-to-understand terms and use the
>> > user-facing behavior instead of technical terms like z-order, so that
>> > I could at least make up my mind whether this issue is serious, and
>> > perhaps think about alternative solutions?  E.g., I don't yet
>> > understand why returning early in x_set_title should help here, and
>> > how.
>> 
>> The problem is that KWin apparently focuses a window if its title
>> changes while it is in a different workspace.  That's misbehavior on
>> KWin's part, and likely a bug.
>
> How is this related to "the z-order isn't change" problem which Óscar
> complained about?

Oscar meant that KWin focused the frame without changing the position of
Emacs in the window stack.  That isn't the bug which was reported, Emacs
being focused was.

bug#61337: 29.0.60; Setting frame-title-format makes Emacs to steal focus

[Óscar Fuentes]

Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs@gnu.org> writes:

>> How is this related to "the z-order isn't change" problem which Óscar
>> complained about?
>
> Oscar meant that KWin focused the frame without changing the position of
> Emacs in the window stack.  That isn't the bug which was reported, Emacs
> being focused was.

Right. The part about the z-order not changing just makes the problem
worse.

For instance: let's suppose that Emacs window is hidden by some other
application's window, (Konsole for instance) that also has the focus.
When I switch desktops Emacs will steal the focus, but otherwise the
screen's appearence will not change, which makes me think that Konsole
still has the focus, then I start typing but the input go to Emacs, and
this too often causes a mess.

Same thing could happen even when Emacs' window is visible, of course.
After all, the user does not expect that switching desktops changes the
focus to certain application's window.

As for the proposed workaround, discovering that you have to set
icon-title-format when you change frame-title-format is a bit
problematic. Too many users don't read PROBLEMS, less so for behaviors
that worked fine for ages.

Po: I can open a bug report on KDE, if you wish, although the technical
issue is out of my depth and the user-facing description is too vague,
so if you can provide a description of what Emacs is doing under the
hood that causes KDE to give it the focus, it surely will help.

bug#61337: 29.0.60; Setting frame-title-format makes Emacs to steal focus

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Po Lu <luangruo@yahoo.com>,
>   61337@debbugs.gnu.org
> Date: Thu, 09 Feb 2023 16:32:30 +0100
> 
> > Oscar meant that KWin focused the frame without changing the position of
> > Emacs in the window stack.  That isn't the bug which was reported, Emacs
> > being focused was.
> 
> Right. The part about the z-order not changing just makes the problem
> worse.
> 
> For instance: let's suppose that Emacs window is hidden by some other
> application's window, (Konsole for instance) that also has the focus.
> When I switch desktops Emacs will steal the focus, but otherwise the
> screen's appearence will not change, which makes me think that Konsole
> still has the focus, then I start typing but the input go to Emacs, and
> this too often causes a mess.
> 
> Same thing could happen even when Emacs' window is visible, of course.
> After all, the user does not expect that switching desktops changes the
> focus to certain application's window.

You mean, you rely on the focus not to change while Emacs's desktop is
not shown?  But if some idle timer causes Emacs to raise a frame, you
will also see Emacs with focus when you switch desktops, right?

I'm not sure I understand the basis for this expectation.  I'd
certainly not even remember in which state I left the applications
before switching away, and will look first when I switch back.
because applications can request focus for any number of reasons.

So I'm surprised that the fact that Emacs gets focus without your
knowing is regarded as a problem at all.

bug#61337: 29.0.60; Setting frame-title-format makes Emacs to steal focus

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> > Oscar meant that KWin focused the frame without changing the position of
>> > Emacs in the window stack.  That isn't the bug which was reported, Emacs
>> > being focused was.
>> 
>> Right. The part about the z-order not changing just makes the problem
>> worse.
>> 
>> For instance: let's suppose that Emacs window is hidden by some other
>> application's window, (Konsole for instance) that also has the focus.
>> When I switch desktops Emacs will steal the focus, but otherwise the
>> screen's appearence will not change, which makes me think that Konsole
>> still has the focus, then I start typing but the input go to Emacs, and
>> this too often causes a mess.
>> 
>> Same thing could happen even when Emacs' window is visible, of course.
>> After all, the user does not expect that switching desktops changes the
>> focus to certain application's window.
>
> You mean, you rely on the focus not to change while Emacs's desktop is
> not shown?  But if some idle timer causes Emacs to raise a frame, you
> will also see Emacs with focus when you switch desktops, right?
>
> I'm not sure I understand the basis for this expectation.  I'd
> certainly not even remember in which state I left the applications
> before switching away, and will look first when I switch back.

Sure, but on this case you will see that Konsole's window is covering
Emacs' (if Emacs' window is visible at all), so you assume that Konsole
has the focus. For avoiding that you must take care of looking at some
place that indicates which window has or has not focus (usually the
window's title bar) noticing that Konsole has no focus, and perform an
action to either give focus to Konsole or bring Emacs' window to the
front.

> because applications can request focus for any number of reasons.
>
> So I'm surprised that the fact that Emacs gets focus without your
> knowing is regarded as a problem at all.

Focus stealing is widely regarded as a very rude action. Imagine you are
typing on some application and suddenly some other application pops out
and starts receiving your keypresses. That's a disaster, even a gross
security issue. Modern desktop environments implement a notification
system to make possible for an application to show information or
request user attention without stealing the focus, so nowadays there is
no good reason for getting focus without the user's request. AFAIR in
Wayland it is simply not possible for an application to forcibly get the
focus.

Certainly, just switching destktops is not one good reason for stealing
the focus.

bug#61337: 29.0.60; Setting frame-title-format makes Emacs to steal focus

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Cc: luangruo@yahoo.com,  61337@debbugs.gnu.org
> Date: Thu, 09 Feb 2023 17:17:40 +0100
> 
> > You mean, you rely on the focus not to change while Emacs's desktop is
> > not shown?  But if some idle timer causes Emacs to raise a frame, you
> > will also see Emacs with focus when you switch desktops, right?
> >
> > I'm not sure I understand the basis for this expectation.  I'd
> > certainly not even remember in which state I left the applications
> > before switching away, and will look first when I switch back.
> 
> Sure, but on this case you will see that Konsole's window is covering
> Emacs' (if Emacs' window is visible at all), so you assume that Konsole
> has the focus. For avoiding that you must take care of looking at some
> place that indicates which window has or has not focus (usually the
> window's title bar) noticing that Konsole has no focus, and perform an
> action to either give focus to Konsole or bring Emacs' window to the
> front.

Of course.  But this need to make sure the window which has input
focus is the one you think it is, is something routine in a windowed
environment, IME.

> > because applications can request focus for any number of reasons.
> >
> > So I'm surprised that the fact that Emacs gets focus without your
> > knowing is regarded as a problem at all.
> 
> Focus stealing is widely regarded as a very rude action.

Happens to me all the time, and at least sometimes for good reasons:
for example, if a program pops up an abort dialog, it is completely
reasonable for it to steal focus.  Similarly any other event that
requires an immediate attention from the user.

> Certainly, just switching destktops is not one good reason for stealing
> the focus.

Once again, you assume that nothing happened except switching
desktops, but that assumption doesn't have a very solid basis.

But I guess we will need to agree to disagree here.

bug#61337: 29.0.60; Setting frame-title-format makes Emacs to steal focus

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

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Óscar Fuentes <ofv@wanadoo.es>
>> Cc: luangruo@yahoo.com,  61337@debbugs.gnu.org
>> Date: Thu, 09 Feb 2023 17:17:40 +0100
>> 
>> > You mean, you rely on the focus not to change while Emacs's desktop is
>> > not shown?  But if some idle timer causes Emacs to raise a frame, you
>> > will also see Emacs with focus when you switch desktops, right?
>> >
>> > I'm not sure I understand the basis for this expectation.  I'd
>> > certainly not even remember in which state I left the applications
>> > before switching away, and will look first when I switch back.
>> 
>> Sure, but on this case you will see that Konsole's window is covering
>> Emacs' (if Emacs' window is visible at all), so you assume that Konsole
>> has the focus. For avoiding that you must take care of looking at some
>> place that indicates which window has or has not focus (usually the
>> window's title bar) noticing that Konsole has no focus, and perform an
>> action to either give focus to Konsole or bring Emacs' window to the
>> front.
>
> Of course.  But this need to make sure the window which has input
> focus is the one you think it is, is something routine in a windowed
> environment, IME.
>
>> > because applications can request focus for any number of reasons.
>> >
>> > So I'm surprised that the fact that Emacs gets focus without your
>> > knowing is regarded as a problem at all.
>> 
>> Focus stealing is widely regarded as a very rude action.
>
> Happens to me all the time, and at least sometimes for good reasons:
> for example, if a program pops up an abort dialog, it is completely
> reasonable for it to steal focus.  Similarly any other event that
> requires an immediate attention from the user.
>
>> Certainly, just switching destktops is not one good reason for stealing
>> the focus.
>
> Once again, you assume that nothing happened except switching
> desktops, but that assumption doesn't have a very solid basis.
>
> But I guess we will need to agree to disagree here.

I think you are both arguing over a misunderstanding.

Oscar's problem is that KWin focuses Emacs when it really should not,
when Emacs has done nothing to ask for the focus, and is in fact
iconified in a different desktop.

And even worse, that focus is set in a way that cannot easily be
perceived by the user.

bug#61337: 29.0.60; Setting frame-title-format makes Emacs to steal focus

[Óscar Fuentes]

Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs@gnu.org> writes:

>> But I guess we will need to agree to disagree here.
>
> I think you are both arguing over a misunderstanding.
>
> Oscar's problem is that KWin focuses Emacs when it really should not,
> when Emacs has done nothing to ask for the focus, and is in fact
> iconified in a different desktop.

Just to clarify, from the user's POV Emacs is not iconified. IIRC you
explained that when we switch desktops, the windows in the previously
selected desktop change to the iconified state, but that's an
implementation detail of the window manager. I hope I got this right.

I just checked that if the user iconifies (minimizes) Emacs' window
before he switches desktops, the focus does not change.

> And even worse, that focus is set in a way that cannot easily be
> perceived by the user.

Exactly that. Thanks for explaining the problem in clear terms.

bug#61337: 29.0.60; Setting frame-title-format makes Emacs to steal focus

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Óscar Fuentes <ofv@wanadoo.es>,  61337@debbugs.gnu.org
> Date: Fri, 10 Feb 2023 10:15:48 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > But I guess we will need to agree to disagree here.
> 
> I think you are both arguing over a misunderstanding.

I don't see a misunderstanding between us.

> Oscar's problem is that KWin focuses Emacs when it really should not,
> when Emacs has done nothing to ask for the focus, and is in fact
> iconified in a different desktop.

I understand that.  I'm just saying that an Emacs user, even a user
such as myself, who knows one or two things about Emacs, has no way of
knowing whether, while the user was away of working with a desktop,
something happened that caused Emacs or WM to switch focus to the
Emacs's window on that desktop.  The events that can cause this on a
modern system are a legion, and can be caused both by what Emacs does
in the background and by the system for any number of valid reasons.

Therefore, the first thing I, as a user, do when I want to resume my
work, is to find out which window has the input focus; I do NOT rely
on some prior knowledge of where I think the focus should be.

> And even worse, that focus is set in a way that cannot easily be
> perceived by the user.

If the WM doesn't provide good ways for the user to tell which window
has input focus, not even as a user customization, that WM is buggy
and should be fixed.  But that is definitely not a problem for us to
solve.

bug#61337: 29.0.60; Setting frame-title-format makes Emacs to steal focus

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

Óscar Fuentes <ofv@wanadoo.es> writes:

> Right. The part about the z-order not changing just makes the problem
> worse.
>
> For instance: let's suppose that Emacs window is hidden by some other
> application's window, (Konsole for instance) that also has the focus.
> When I switch desktops Emacs will steal the focus, but otherwise the
> screen's appearence will not change, which makes me think that Konsole
> still has the focus, then I start typing but the input go to Emacs, and
> this too often causes a mess.
>
> Same thing could happen even when Emacs' window is visible, of course.
> After all, the user does not expect that switching desktops changes the
> focus to certain application's window.
>
> As for the proposed workaround, discovering that you have to set
> icon-title-format when you change frame-title-format is a bit
> problematic. Too many users don't read PROBLEMS, less so for behaviors
> that worked fine for ages.

Well, the problem isn't that frame-title-format worked, it's that
icon-title-format did not work for a very long time.

> Po: I can open a bug report on KDE, if you wish, although the technical
> issue is out of my depth and the user-facing description is too vague,
> so if you can provide a description of what Emacs is doing under the
> hood that causes KDE to give it the focus, it surely will help.

I would recommend saying:

  Window in another desktop ends up focused upon returning to that
  desktop if it changes WM_NAME and _NET_WM_NAME while in an iconic
  state.

bug#61337: 29.0.60; Setting frame-title-format makes Emacs to steal focus

[Óscar Fuentes]

Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs@gnu.org> writes:

> I would recommend saying:
>
>   Window in another desktop ends up focused upon returning to that
>   desktop if it changes WM_NAME and _NET_WM_NAME while in an iconic
>   state.

Thank you. I copied that paragraph in the KDE bug report:

https://bugs.kde.org/show_bug.cgi?id=465530

bug#61337: 29.0.60; Setting frame-title-format makes Emacs to steal focus

[Óscar Fuentes]

Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs@gnu.org> writes:

> I would recommend saying:
>
>   Window in another desktop ends up focused upon returning to that
>   desktop if it changes WM_NAME and _NET_WM_NAME while in an iconic
>   state.

Indeed, that's what KDE does in certain conditions (see details on the
KDE bug report (1)). I made a reproducer that does not require Emacs.

Later I will open a bug report about the default value of
icon-title-format. Now closing this one.

Thank you.

1. https://bugs.kde.org/show_bug.cgi?id=465530#c13

bug#61337: 29.0.60; Setting frame-title-format makes Emacs to steal focus

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

Óscar Fuentes <ofv@wanadoo.es> writes:

> Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text
> editors" <bug-gnu-emacs@gnu.org> writes:
>
>> I would recommend saying:
>>
>>   Window in another desktop ends up focused upon returning to that
>>   desktop if it changes WM_NAME and _NET_WM_NAME while in an iconic
>>   state.
>
> Indeed, that's what KDE does in certain conditions (see details on the
> KDE bug report (1)). I made a reproducer that does not require Emacs.
>
> Later I will open a bug report about the default value of
> icon-title-format. Now closing this one.
>
> Thank you.
>
> 1. https://bugs.kde.org/show_bug.cgi?id=465530#c13

Thanks.