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

Previous Next

Full log

View this message in rfc822 format

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

Previous Next

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