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" <bug-gnu-emacs@gnu.org>]

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.