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

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

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

arthur miller

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 :-).




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))

poor-man-menu.el (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Lars Ingebrigtsen
Arthur Miller <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

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

arthur miller
Lars Ingebrigtsen <[hidden email]> writes:

> Arthur Miller <[hidden email]> 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.



Reply | Threaded
Open this post in threaded view
|

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

Lars Ingebrigtsen
Arthur Miller <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

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

martin rudalics
In reply to this post by arthur miller
 > 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



Reply | Threaded
Open this post in threaded view
|

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

martin rudalics
In reply to this post by Lars Ingebrigtsen
 > 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



Reply | Threaded
Open this post in threaded view
|

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

Lars Ingebrigtsen
In reply to this post by Lars Ingebrigtsen
Arthur Miller <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

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

martin rudalics
 > 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



Reply | Threaded
Open this post in threaded view
|

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

Lars Ingebrigtsen
martin rudalics <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

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

arthur miller
In reply to this post by martin rudalics
martin rudalics <[hidden email]> 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.




Reply | Threaded
Open this post in threaded view
|

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

martin rudalics
 > 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



Reply | Threaded
Open this post in threaded view
|

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

arthur miller
martin rudalics <[hidden email]> 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?



Reply | Threaded
Open this post in threaded view
|

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

martin rudalics
 > 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



Reply | Threaded
Open this post in threaded view
|

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

arthur miller
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 <[hidden email]>
Datum: 2020-09-30 19:33 (GMT+01:00)
Till: Arthur Miller <[hidden email]>
Kopia: Lars Ingebrigtsen <[hidden email]>, [hidden email]
Ä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
Reply | Threaded
Open this post in threaded view
|

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

martin rudalics
 > 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




Reply | Threaded
Open this post in threaded view
|

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

arthur miller
martin rudalics <[hidden email]> 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 (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

martin rudalics
 > 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



Reply | Threaded
Open this post in threaded view
|

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

arthur miller
martin rudalics <[hidden email]> 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.



Reply | Threaded
Open this post in threaded view
|

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

martin rudalics
 > 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