GNU bug report logs - #43672
28.0.50; select-frame-set-input-focus does not set focus first time called

Previous Next

To reply to this bug, email your comments to 43672 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Arthur Miller <arthur.miller <at> live.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.50; select-frame-set-input-focus does not set focus first time
 called
Date: Mon, 28 Sep 2020 15:34:33 +0200

[Message part 1 (text/plain, inline)]

When calling

      (select-frame-set-input-focus some-frame)

the frame is raised, but does not recieve the focus. I have to call 
twice to 'select-frame-set-input-focus' for the frame to get
focused. Docs says "focused if possible", so I am not sure if it some
bug or/and how much does it depend on my window manager used; but
calling it twice consecutively works.

I have attached an example code. To reproduce, emacs -Q, an eval
attached code.

If I missunderstand docs, or am calling it wrongly, dissregard the
rapport plz :-).

[poor-man-menu.el (text/plain, attachment)]

[Message part 3 (text/plain, inline)]

In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.23, cairo version 1.17.3)
 of 2020-09-27 built on pascal
Repository revision: dc0cf16c7a60f36aafcf9b56513a855cefa7e1ad
Repository branch: feature/native-comp
Windowing system distributor 'The X.Org Foundation', version 11.0.12009000
System Description: Arch Linux

Configured using:
 'configure --with-gnutls --without-gconf --with-rsvg --with-x
 --with-xwidgets --without-toolkit-scroll-bars --without-xaw3d
 --without-gsettings --with-mailutils --with-nativecomp 'CFLAGS=-O3
 -mtune=native -march=native -fomit-frame-pointer''

Configured features:
XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND GPM DBUS GLIB NOTIFY INOTIFY ACL
GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF ZLIB GTK3 X11 XDBE XIM
MODULES NATIVE_COMP THREADS XWIDGETS LIBSYSTEMD JSON PDUMPER LCMS2

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

Major mode: ELisp/l

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-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
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml easymenu mml-sec epa derived epg epg-config gnus-util rmail
rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json map text-property-search seq byte-opt
gv bytecomp byte-compile cconv mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils edmacro kmacro time-date subr-x
cl-loaddefs cl-lib pure-menu easy-mmode tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type 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 elisp-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame minibuffer cl-generic 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 charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice button
loaddefs faces cus-face pcase macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote threads xwidget-internal dbusbind
inotify lcms2 dynamic-setting font-render-setting cairo move-toolbar gtk
x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 65534 9142)
 (symbols 48 7061 0)
 (strings 32 19304 1280)
 (string-bytes 1 699011)
 (vectors 16 12611)
 (vector-slots 8 276483 9931)
 (floats 8 26 105)
 (intervals 56 610 517)
 (buffers 992 13))

Message #8 received at 43672 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Arthur Miller <arthur.miller <at> live.com>
Cc: 43672 <at> debbugs.gnu.org
Subject: Re: bug#43672: 28.0.50; select-frame-set-input-focus does not set
 focus first time called
Date: Mon, 28 Sep 2020 15:57:56 +0200

Arthur Miller <arthur.miller <at> live.com> writes:

> When calling
>
>       (select-frame-set-input-focus some-frame)
>
> the frame is raised, but does not recieve the focus.


[...]

> (define-minor-mode pm-minor-mode
>   :keymap (let ((map (make-sparse-keymap)))
>             map))

This isn't valid (lacks a doc string), but after fixing it, I'm unable
to reproduce the bug?  I think?  At least my frame lost focus, but the
other frame never really appeared in any visible sense.

It did something really weird to my Gnome Shell desktop -- even after
closing the Emacs that opened the frames, Gnome Shell insists that
they're there, but not responding.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #11 received at 43672 <at> debbugs.gnu.org (full text, mbox):

From: Arthur Miller <arthur.miller <at> live.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 43672 <at> debbugs.gnu.org
Subject: Re: bug#43672: 28.0.50; select-frame-set-input-focus does not set
 focus first time called
Date: Mon, 28 Sep 2020 16:11:48 +0200

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Arthur Miller <arthur.miller <at> live.com> writes:
>
>> When calling
>>
>>       (select-frame-set-input-focus some-frame)
>>
>> the frame is raised, but does not recieve the focus.
>
>
> [...]
>
>> (define-minor-mode pm-minor-mode
>>   :keymap (let ((map (make-sparse-keymap)))
>>             map))
>
> This isn't valid (lacks a doc string),
Ah, ok; It was just a quickie to let me close menu without M-x
delete-frame when I test.

> but after fixing it, I'm unable
> to reproduce the bug?  I think?  At least my frame lost focus, but the
> other frame never really appeared in any visible sense. Can
it be it just ended somewhere outside the screen?

Did you run via the "test" function (pm-test)? It should take pixel
coordinate of the point and try to place the frame at those coords.

> It did something really weird to my Gnome Shell desktop -- even after
> closing the Emacs that opened the frames, Gnome Shell insists that
> they're there, but not responding.
That sounds really weird. The code does notthing special; it just
creates a child frame, and tries to display a buffer in it.

On my machine (I use Compiz as WM), it displays properly, either at
point or cursor. It is just that focus does not get transfered as
advertised (as I understand it).

Thanks for looking at it.

Message #14 received at 43672 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Arthur Miller <arthur.miller <at> live.com>
Cc: 43672 <at> debbugs.gnu.org
Subject: Re: bug#43672: 28.0.50; select-frame-set-input-focus does not set
 focus first time called
Date: Mon, 28 Sep 2020 16:14:46 +0200

Arthur Miller <arthur.miller <at> live.com> writes:

> Can it be it just ended somewhere outside the screen?

It's possible.

> Did you run via the "test" function (pm-test)? It should take pixel
> coordinate of the point and try to place the frame at those coords.

Yes, I did M-x pm-test.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #17 received at 43672 <at> debbugs.gnu.org (full text, mbox):

From: Arthur Miller <arthur.miller <at> live.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 43672 <at> debbugs.gnu.org
Subject: Re: bug#43672: 28.0.50; select-frame-set-input-focus does not set
 focus first time called
Date: Mon, 28 Sep 2020 16:40:12 +0200

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Arthur Miller <arthur.miller <at> live.com> writes:
>
>> Can it be it just ended somewhere outside the screen?
>
> It's possible.

I usually click somewhere in the middle of the screen in Emacs when I
test :-). The code is just a rough scatch, I was just playing with an
idea to see if it could work. You can also try to change the test
function to pm-show-at-cursor, and just have the cursor somewhere in the
window. 

>> Did you run via the "test" function (pm-test)? It should take pixel
>> coordinate of the point and try to place the frame at those coords.
>
> Yes, I did M-x pm-test.
I can't tell, if it has something to do with Gnome shell; I don't have
it installed myself; but than it is probably a bug? Emacs should display
and kill child frames correctly regardless of the window manager.

Message #20 received at 43672 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Arthur Miller <arthur.miller <at> live.com>, 43672 <at> debbugs.gnu.org
Subject: Re: bug#43672: 28.0.50; select-frame-set-input-focus does not set
 focus first time called
Date: Mon, 28 Sep 2020 19:59:08 +0200

> When calling
>
>        (select-frame-set-input-focus some-frame)
>
> the frame is raised, but does not recieve the focus. I have to call
> twice to 'select-frame-set-input-focus' for the frame to get
> focused. Docs says "focused if possible", so I am not sure if it some
> bug or/and how much does it depend on my window manager used; but
> calling it twice consecutively works.
>
> I have attached an example code. To reproduce, emacs -Q, an eval
> attached code.

These two settings don't make much sense

          (child-frame (make-frame   '((visible . 0)
                                       (undecorated . 0)

For the moment let's stick to the simpler

(defvar child-frame nil)

(defun make-child-frame ()
  (interactive)
  (setq child-frame
	(make-frame `((parent-frame . ,(selected-frame))
		      (left . 10)
		      (top . 10)
		      (width . 20)
		      (height . 10))))
  (select-frame-set-input-focus child-frame))

(defun delete-child-frame ()
  (interactive)
  (delete-frame child-frame))

If you call 'make-child-frame', does the child frame get selected?

If not, we have to try some workaround, maybe a (sit-for 0) before the
'select-frame-set-input-focus' call.

martin

Message #23 received at 43672 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Arthur Miller <arthur.miller <at> live.com>
Cc: 43672 <at> debbugs.gnu.org
Subject: Re: bug#43672: 28.0.50; select-frame-set-input-focus does not set
 focus first time called
Date: Mon, 28 Sep 2020 19:59:23 +0200

> It did something really weird to my Gnome Shell desktop -- even after
> closing the Emacs that opened the frames, Gnome Shell insists that
> they're there, but not responding.

Maybe the child frame 1-to-1 covers its parent.  Either way Gnome Shell
(mutter) doesn't like child frames.

martin

Message #26 received at 43672 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Arthur Miller <arthur.miller <at> live.com>
Cc: 43672 <at> debbugs.gnu.org
Subject: Re: bug#43672: 28.0.50; select-frame-set-input-focus does not set
 focus first time called
Date: Tue, 29 Sep 2020 15:46:49 +0200

Arthur Miller <arthur.miller <at> live.com> writes:

> I can't tell, if it has something to do with Gnome shell; I don't have
> it installed myself; but than it is probably a bug? Emacs should display
> and kill child frames correctly regardless of the window manager.

Indeed.  After closing the other windows here, I saw that the frames
were sitting in the background, but with no way to interact with them.
(Even after the Emacs process was long gone.)  This has to be a bug in
Gnome Shell, but it means that I can't debug the reported error here, so
somebody else will have to look at it.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #29 received at 43672 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Arthur Miller <arthur.miller <at> live.com>
Cc: 43672 <at> debbugs.gnu.org
Subject: Re: bug#43672: 28.0.50; select-frame-set-input-focus does not set
 focus first time called
Date: Tue, 29 Sep 2020 16:34:18 +0200

> Indeed.  After closing the other windows

"windows"?

> here, I saw that the frames
> were sitting in the background, but with no way to interact with them.
> (Even after the Emacs process was long gone.)  This has to be a bug in
> Gnome Shell, but it means that I can't debug the reported error here, so
> somebody else will have to look at it.

Have you tried with the simpler scenario I posted?

In either case, with xfwm here the child frame gets selected as
expected.

martin

Message #32 received at 43672 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Arthur Miller <arthur.miller <at> live.com>, 43672 <at> debbugs.gnu.org
Subject: Re: bug#43672: 28.0.50; select-frame-set-input-focus does not set
 focus first time called
Date: Tue, 29 Sep 2020 16:44:11 +0200

martin rudalics <rudalics <at> gmx.at> writes:

>> Indeed.  After closing the other windows
>
> "windows"?

Yes, like the Firefox window.  :-)

>> here, I saw that the frames
>> were sitting in the background, but with no way to interact with them.
>> (Even after the Emacs process was long gone.)  This has to be a bug in
>> Gnome Shell, but it means that I can't debug the reported error here, so
>> somebody else will have to look at it.
>
> Have you tried with the simpler scenario I posted?

Nope.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #35 received at 43672 <at> debbugs.gnu.org (full text, mbox):

From: Arthur Miller <arthur.miller <at> live.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 43672 <at> debbugs.gnu.org
Subject: Re: bug#43672: 28.0.50; select-frame-set-input-focus does not set
 focus first time called
Date: Tue, 29 Sep 2020 22:43:05 +0200

martin rudalics <rudalics <at> gmx.at> writes:

>> Indeed.  After closing the other windows
>
> "windows"?
>
>> here, I saw that the frames
>> were sitting in the background, but with no way to interact with them.
>> (Even after the Emacs process was long gone.)  This has to be a bug in
>> Gnome Shell, but it means that I can't debug the reported error here, so
>> somebody else will have to look at it.
>
> Have you tried with the simpler scenario I posted?
>
> In either case, with xfwm here the child frame gets selected as
> expected.
>
> martin

I can't say why, but today this works fine with my "normal emacs"; with
all packages loaded and running as server/client.

When I start with emacs -Q then it does not work; it needs two calls to
select-frame-set-input-focus.

I thought it might have something to do with focus and how WM raises
windows and gives focus; normally I have focus follow mouse but not auto
raising enabled. I have disabled auto-focus (need click into window to
give focus) but I see no difference in behaviour.

Message #38 received at 43672 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Arthur Miller <arthur.miller <at> live.com>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 43672 <at> debbugs.gnu.org
Subject: Re: bug#43672: 28.0.50; select-frame-set-input-focus does not set
 focus first time called
Date: Wed, 30 Sep 2020 10:15:38 +0200

> I can't say why, but today this works fine with my "normal emacs"; with
> all packages loaded and running as server/client.
>
> When I start with emacs -Q then it does not work; it needs two calls to
> select-frame-set-input-focus.

That is, you can interleave normal and -Q sessions and in the normal
session "this works" and in the -Q session it doesn't?  Then I'm afraid
that you have to bisect the things you do in your normal session to find
out what makes "this work".

> I thought it might have something to do with focus and how WM raises
> windows and gives focus; normally I have focus follow mouse but not auto
> raising enabled. I have disabled auto-focus (need click into window to
> give focus) but I see no difference in behaviour.

By design, auto-focus should only affect mouse movements.  One recurring
problem is, however, whether the WM should auto-move the mouse pointer
to a freshly displayed window in order to make sure that if the mouse
pointer was located on another window, that window would not regain
focus immediately due to your auto-focus settings.  Note that that
window _should_ retain focus when you specified 'no-focus-on-map' for
the new frame but IIUC you did not do that.

martin

Message #41 received at 43672 <at> debbugs.gnu.org (full text, mbox):

From: Arthur Miller <arthur.miller <at> live.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 43672 <at> debbugs.gnu.org
Subject: Re: bug#43672: 28.0.50; select-frame-set-input-focus does not set
 focus first time called
Date: Wed, 30 Sep 2020 11:31:16 +0200

martin rudalics <rudalics <at> gmx.at> writes:

>> I can't say why, but today this works fine with my "normal emacs"; with
>> all packages loaded and running as server/client.
>>
>> When I start with emacs -Q then it does not work; it needs two calls to
>> select-frame-set-input-focus.
>
> That is, you can interleave normal and -Q sessions and in the normal
> session "this works" and in the -Q session it doesn't?  Then I'm afraid
> that you have to bisect the things you do in your normal session to find
> out what makes "this work".
I just did; seems it has something with server/client to do.

It works in emacsclient; not when running as ordinary process. Tryed
both as emacs -Q, and with my init file.

>> I thought it might have something to do with focus and how WM raises
>> windows and gives focus; normally I have focus follow mouse but not auto
>> raising enabled. I have disabled auto-focus (need click into window to
>> give focus) but I see no difference in behaviour.
>
> By design, auto-focus should only affect mouse movements.  One recurring
> problem is, however, whether the WM should auto-move the mouse pointer
> to a freshly displayed window in order to make sure that if the mouse
> pointer was located on another window, that window would not regain
> focus immediately due to your auto-focus settings.  Note that that
> window _should_ retain focus when you specified 'no-focus-on-map' for
> the new frame but IIUC you did not do that.
In Compiz; the newly created window does get focus, but the mouse is not
moved; if mouse is noved then focus switches again; but this did not
spooked. It seems that it has something to do if it is emacs or
emacsclient.

I don't know how emacsclient works; maybe it just does not pass all
requests to the server correctly?

Message #44 received at 43672 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Arthur Miller <arthur.miller <at> live.com>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 43672 <at> debbugs.gnu.org
Subject: Re: bug#43672: 28.0.50; select-frame-set-input-focus does not set
 focus first time called
Date: Wed, 30 Sep 2020 19:33:27 +0200

> I just did; seems it has something with server/client to do.
>
> It works in emacsclient; not when running as ordinary process. Tryed
> both as emacs -Q, and with my init file.

Do I understand you correctly that it works for emacsclient but not for
emacs itself?

> I don't know how emacsclient works; maybe it just does not pass all
> requests to the server correctly?

I'm confused.  Above you say that it works with emacsclient ...

martin

Message #47 received at 43672 <at> debbugs.gnu.org (full text, mbox):

From: arthur miller <arthur.miller <at> live.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>,
 "43672 <at> debbugs.gnu.org" <43672 <at> debbugs.gnu.org>
Subject: RE: bug#43672: 28.0.50; select-frame-set-input-focus does not set
 focus first time called
Date: Wed, 30 Sep 2020 17:36:37 +0000

[Message part 1 (text/plain, inline)]

I am sorry för the confusion, I was just to fast typing. Yes, you understand me correctly. It works correctly in emacsclient; not correctly when I run Emacs as a standalone process, either with -Q flag or without.






-------- Originalmeddelande --------
Från: martin rudalics <rudalics <at> gmx.at>
Datum: 2020-09-30 19:33 (GMT+01:00)
Till: Arthur Miller <arthur.miller <at> live.com>
Kopia: Lars Ingebrigtsen <larsi <at> gnus.org>, 43672 <at> debbugs.gnu.org
Ämne: Re: bug#43672: 28.0.50; select-frame-set-input-focus does not set focus first time called

> I just did; seems it has something with server/client to do.
 >
 > It works in emacsclient; not when running as ordinary process. Tryed
 > both as emacs -Q, and with my init file.

Do I understand you correctly that it works for emacsclient but not for
emacs itself?

 > I don't know how emacsclient works; maybe it just does not pass all
 > requests to the server correctly?

I'm confused.  Above you say that it works with emacsclient ...

martin

[Message part 2 (text/html, inline)]

Message #50 received at 43672 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: arthur miller <arthur.miller <at> live.com>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>,
 "43672 <at> debbugs.gnu.org" <43672 <at> debbugs.gnu.org>
Subject: Re: bug#43672: 28.0.50; select-frame-set-input-focus does not set
 focus first time called
Date: Thu, 1 Oct 2020 10:39:15 +0200

> I am sorry för the confusion, I was just to fast typing. Yes, you
> understand me correctly. It works correctly in emacsclient; not
> correctly when I run Emacs as a standalone process, either with -Q
> flag or without.

Then please with emacs -Q try the simpler

(defvar child-frame nil)

(defun make-child-frame ()
  (interactive)
  (setq child-frame
    (make-frame `((parent-frame . ,(selected-frame))
              (left . 10)
              (top . 10)
              (width . 20)
              (height . 10))))
  (select-frame-set-input-focus child-frame))

(defun delete-child-frame ()
  (interactive)
  (delete-frame child-frame))

and tell us whether the child frame gets focus.

martin

Message #53 received at 43672 <at> debbugs.gnu.org (full text, mbox):

From: Arthur Miller <arthur.miller <at> live.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>,
 "43672 <at> debbugs.gnu.org" <43672 <at> debbugs.gnu.org>
Subject: Re: bug#43672: 28.0.50; select-frame-set-input-focus does not set
 focus first time called
Date: Sat, 17 Oct 2020 23:51:16 +0200

[Message part 1 (text/plain, inline)]

martin rudalics <rudalics <at> gmx.at> writes:

>> I am sorry för the confusion, I was just to fast typing. Yes, you
>> understand me correctly. It works correctly in emacsclient; not
>> correctly when I run Emacs as a standalone process, either with -Q
>> flag or without.
>
> Then please with emacs -Q try the simpler
>
> (defvar child-frame nil)
>
> (defun make-child-frame ()
>   (interactive)
>   (setq child-frame
>     (make-frame `((parent-frame . ,(selected-frame))
>               (left . 10)
>               (top . 10)
>               (width . 20)
>               (height . 10))))
>   (select-frame-set-input-focus child-frame))
>
> (defun delete-child-frame ()
>   (interactive)
>   (delete-frame child-frame))
>
> and tell us whether the child frame gets focus.
>
> martin
Hello Martin,

sorry for being a bit late with this. I have tested and it was very
strange, so I realized I need more time to play with it.

Here is how I got it:

If I pass parent in the frame-params list to make-frame, then all is
grandy-dandy; but if I don't then the behaviour is as following:

If parent is set after creation; the frame will be reparented correctly
and appear at correct place on the screen, but it won't switch focus.

If parent is not set after the creation; the frame will switch focus,
buf it will of course appear somewhere at the screen (absolute
coordinates I guess).

I have tested only emacsclient. I hope it helps.

I have attached a simplified test file:

[poorman-menu.el (text/plain, attachment)]

Message #56 received at 43672 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Arthur Miller <arthur.miller <at> live.com>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>,
 "43672 <at> debbugs.gnu.org" <43672 <at> debbugs.gnu.org>
Subject: Re: bug#43672: 28.0.50; select-frame-set-input-focus does not set
 focus first time called
Date: Sun, 18 Oct 2020 09:56:38 +0200

> sorry for being a bit late with this. I have tested and it was very
> strange, so I realized I need more time to play with it.
>
> Here is how I got it:
>
> If I pass parent in the frame-params list to make-frame, then all is
> grandy-dandy;

Even without emacsclient?

> but if I don't then the behaviour is as following:
>
> If parent is set after creation; the frame will be reparented correctly
> and appear at correct place on the screen, but it won't switch focus.

But it eventually does get focus if you insist by executing
'select-frame-set-input-focus' twice.  Right?

> If parent is not set after the creation; the frame will switch focus,
> buf it will of course appear somewhere at the screen (absolute
> coordinates I guess).
>
> I have tested only emacsclient. I hope it helps.

Earlier you said:

  It works correctly in emacsclient; not correctly when I run Emacs as a
  standalone process, either with -Q flag or without.

So shouldn't you try with a standalone Emacs?

> I have attached a simplified test file:

If setting the parent in 'make-frame' works, then we can warn about
reparenting later possibly causing problems with focus transfer.  But if
the problematic behavior occurs when you want to pop up an (already
existing but invisible) child menu frame on a different parent and give
the menu focus, I have no idea what to do.  So does the latter work for
you?

martin

Message #59 received at 43672 <at> debbugs.gnu.org (full text, mbox):

From: Arthur Miller <arthur.miller <at> live.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>,
 "43672 <at> debbugs.gnu.org" <43672 <at> debbugs.gnu.org>
Subject: Re: bug#43672: 28.0.50; select-frame-set-input-focus does not set
 focus first time called
Date: Sun, 18 Oct 2020 16:10:44 +0200

martin rudalics <rudalics <at> gmx.at> writes:

>> sorry for being a bit late with this. I have tested and it was very
>> strange, so I realized I need more time to play with it.
>>
>> Here is how I got it:
>>
>> If I pass parent in the frame-params list to make-frame, then all is
>> grandy-dandy;
>
> Even without emacsclient?
No I tested emacsclient only; didn't have time to test more I had to go
to sleep :-) 
>> but if I don't then the behaviour is as following:
>>
>> If parent is set after creation; the frame will be reparented correctly
>> and appear at correct place on the screen, but it won't switch focus.
>
> But it eventually does get focus if you insist by executing
> 'select-frame-set-input-focus' twice.  Right?
Yes. I think I said that  previously; tested now and it works when
setting focus twice.

>> If parent is not set after the creation; the frame will switch focus,
>> buf it will of course appear somewhere at the screen (absolute
>> coordinates I guess).
>>
>> I have tested only emacsclient. I hope it helps.
>
> Earlier you said:
>
>   It works correctly in emacsclient; not correctly when I run Emacs as a
>   standalone process, either with -Q flag or without.
>
> So shouldn't you try with a standalone Emacs?
Yes I know; but now I get the behaviour as described in the previous
mail in client too.

I have just tested with emacs -Q too, and I get same behaviour, so at
least now it seems to behave same in both client and standalone process.

>> I have attached a simplified test file:
>
> If setting the parent in 'make-frame' works, then we can warn about
> reparenting later possibly causing problems with focus transfer.  But
> if
Personally I can live with this, it is not problem for me; I reported
mostly because I thought it was rather an odd behaviour. I understand
it's a picky thing to debug.
> But if
> the problematic behavior occurs when you want to pop up an (already
> existing but invisible) child menu frame on a different parent and give
> the menu focus, I have no idea what to do.  So does the latter work for
> you?
I haven't come to that part yet :-). I just started to write a small
eperiment, got into that one and reported, and haven't had time to go
back to my experiment.

Message #62 received at 43672 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Arthur Miller <arthur.miller <at> live.com>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>,
 "43672 <at> debbugs.gnu.org" <43672 <at> debbugs.gnu.org>
Subject: Re: bug#43672: 28.0.50; select-frame-set-input-focus does not set
 focus first time called
Date: Tue, 20 Oct 2020 09:20:45 +0200

> Personally I can live with this, it is not problem for me; I reported
> mostly because I thought it was rather an odd behaviour. I understand
> it's a picky thing to debug.

Transferring focus within or to a parent/child frame combination is a
highly idiosyncratic task.  Maybe because some window managers try to
second-guess the application's or users' intentions.

martin

Message #65 received at 43672 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Arthur Miller <arthur.miller <at> live.com>
Cc: martin rudalics <rudalics <at> gmx.at>,
 "43672 <at> debbugs.gnu.org" <43672 <at> debbugs.gnu.org>
Subject: Re: bug#43672: 28.0.50; select-frame-set-input-focus does not set
 focus first time called
Date: Thu, 21 Apr 2022 16:02:31 +0200

Arthur Miller <arthur.miller <at> live.com> writes:

>> If setting the parent in 'make-frame' works, then we can warn about
>> reparenting later possibly causing problems with focus transfer.  But
>> if
> Personally I can live with this, it is not problem for me; I reported
> mostly because I thought it was rather an odd behaviour. I understand
> it's a picky thing to debug.
>> But if
>> the problematic behavior occurs when you want to pop up an (already
>> existing but invisible) child menu frame on a different parent and give
>> the menu focus, I have no idea what to do.  So does the latter work for
>> you?
> I haven't come to that part yet :-). I just started to write a small
> eperiment, got into that one and reported, and haven't had time to go
> back to my experiment.

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

This was a year ago -- skimming this bug report, it's unclear whether
there's anything to be done on the Emacs side here.  Is further progress
possible in this bug report?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.