bug#29518: 27.0.50; Compilation errors grab frame focus

bug#29518: 27.0.50; Compilation errors grab frame focus

[Eric Abrahamsen]

I've noticed over the past few weeks (couple of months?) that, while
updating packages, any compilation errors result in the *Package List*
frame grabbing focus.

I start a package upgrade, switch to some other program, and then (some
packages produce a lot of errors!) start a focus tug-of-war with the
Emacs frame where the compilation is going on.

I am on arch linux, with no DE, running i3 directly on X. I note that if
I move to a different workspace, compilation errors cause the workspace
where the frame lives to turn red (which seems to be the i3 behavior for
frames with warnings or notifications or whatever the X terminology is),
but I'm not yanked back there. If I'm in that workspace, however, the
Emacs frame keeps jumping to the fore.

I've looked through the Emacs git log to see if anything jumps out as
having been changed, but most of the frame/focus stuff seems NS-related.
But I'm pretty sure this is new behavior.


In GNU Emacs 27.0.50 (build 13, x86_64-pc-linux-gnu, GTK+ Version 3.22.26)
 of 2017-11-30 built on slip
Repository revision: 3f3d98ee5851840228786390ee7dbf851d144eb8
Windowing system distributor 'The X.Org Foundation', version 11.0.11905000

bug#29518: 27.0.50; Compilation errors grab frame focus

[Noam Postavsky]

[-- Attachment #1: Type: text/plain, Size: 1575 bytes --]

tags 29518 + unreproducible
quit

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> I've noticed over the past few weeks (couple of months?) that, while
> updating packages, any compilation errors result in the *Package List*
> frame grabbing focus.
>
> I start a package upgrade, switch to some other program, and then (some
> packages produce a lot of errors!) start a focus tug-of-war with the
> Emacs frame where the compilation is going on.
>
> I am on arch linux, with no DE, running i3 directly on X. I note that if
> I move to a different workspace, compilation errors cause the workspace
> where the frame lives to turn red (which seems to be the i3 behavior for
> frames with warnings or notifications or whatever the X terminology is),
> but I'm not yanked back there. If I'm in that workspace, however, the
> Emacs frame keeps jumping to the fore.
>
> I've looked through the Emacs git log to see if anything jumps out as
> having been changed, but most of the frame/focus stuff seems NS-related.
> But I'm pretty sure this is new behavior.
>
>
> In GNU Emacs 27.0.50 (build 13, x86_64-pc-linux-gnu, GTK+ Version 3.22.26)
>  of 2017-11-30 built on slip
> Repository revision: 3f3d98ee5851840228786390ee7dbf851d144eb8
> Windowing system distributor 'The X.Org Foundation', version 11.0.11905000

I can't reproduce this.  I'm also running i3 directly on X (Debian
stable though).  I tried M-x package-install-file RET some-errors.el RET
(see the attached file) then switch focus to a nearby terminal window.
The compile error did not trigger a change in focus.


[-- Attachment #2: elisp triggering compile error --]
[-- Type: text/plain, Size: 256 bytes --]

;;; some-errors.el --- while ocmpiling

;; Copyright (C) 2008-2017 Free Software Foundation, Inc.
;; Version: 0.1
;; Package-Requires: ((cl-lib "0.5"))


(eval-when-compile
  (sleep-for 1))
(eval-when-compile
  (error "foo"))

;;; some-errors.el ends here

[-- Attachment #3: Type: text/plain, Size: 192 bytes --]


There have been some changes to the way timeouts are handles, which
could affect frame/focusing stuff (see #24091, #25521, and #29095), but
I don't think it should cause what you are seeing.

bug#29518: 27.0.50; Compilation errors grab frame focus

[Eric Abrahamsen]

On 01/06/18 09:50 AM, Noam Postavsky wrote:
> tags 29518 + unreproducible
> quit
>
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> I've noticed over the past few weeks (couple of months?) that, while
>> updating packages, any compilation errors result in the *Package List*
>> frame grabbing focus.
>>
>> I start a package upgrade, switch to some other program, and then (some
>> packages produce a lot of errors!) start a focus tug-of-war with the
>> Emacs frame where the compilation is going on.
>>
>> I am on arch linux, with no DE, running i3 directly on X. I note that if
>> I move to a different workspace, compilation errors cause the workspace
>> where the frame lives to turn red (which seems to be the i3 behavior for
>> frames with warnings or notifications or whatever the X terminology is),
>> but I'm not yanked back there. If I'm in that workspace, however, the
>> Emacs frame keeps jumping to the fore.
>>
>> I've looked through the Emacs git log to see if anything jumps out as
>> having been changed, but most of the frame/focus stuff seems NS-related.
>> But I'm pretty sure this is new behavior.
>>
>>
>> In GNU Emacs 27.0.50 (build 13, x86_64-pc-linux-gnu, GTK+ Version 3.22.26)
>>  of 2017-11-30 built on slip
>> Repository revision: 3f3d98ee5851840228786390ee7dbf851d144eb8
>> Windowing system distributor 'The X.Org Foundation', version 11.0.11905000
>
> I can't reproduce this.  I'm also running i3 directly on X (Debian
> stable though).  I tried M-x package-install-file RET some-errors.el RET
> (see the attached file) then switch focus to a nearby terminal window.
> The compile error did not trigger a change in focus.

Thanks for the test! That triggers the same focus-grabbing behavior for
me -- from other Emacs frames, and other applications' frames, using
"emacs -Q".

You tried this also with switching to a different workspace? And it
didn't turn the workspace's tab red?

Perhaps something's configured differently on my system (though I don't
know why it would be, I didn't customize anything). Is there anything I
might be looking for in config.log?

> There have been some changes to the way timeouts are handles, which
> could affect frame/focusing stuff (see #24091, #25521, and #29095), but
> I don't think it should cause what you are seeing.

I fooled with `x-wait-for-event-timeout' but that didn't do anything. I
suppose 6a788d2fc18c23dcfc5d0352649b2f690e9cbff7 could be related
(FRAME_VISIBLE_P certainly sounds relevant) but I don't actually
understand what's happening in there. Should I try just reverting the
commit and re-building?

Thanks,
Eric

bug#29518: 27.0.50; Compilation errors grab frame focus

[Noam Postavsky]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Thanks for the test! That triggers the same focus-grabbing behavior for
> me -- from other Emacs frames, and other applications' frames, using
> "emacs -Q".
>
> You tried this also with switching to a different workspace? And it
> didn't turn the workspace's tab red?

I tried now switching to a different workspace after starting the
compile, the tab did not turn red.

> Perhaps something's configured differently on my system (though I don't
> know why it would be, I didn't customize anything). Is there anything I
> might be looking for in config.log?

I can't think of anything.  If you M-x debug-on-error RET x-focus-frame
RET do you get any hits?

>> There have been some changes to the way timeouts are handles, which
>> could affect frame/focusing stuff (see #24091, #25521, and #29095), but
>> I don't think it should cause what you are seeing.
>
> I fooled with `x-wait-for-event-timeout' but that didn't do anything. I
> suppose 6a788d2fc18c23dcfc5d0352649b2f690e9cbff7 could be related
> (FRAME_VISIBLE_P certainly sounds relevant) but I don't actually
> understand what's happening in there. Should I try just reverting the
> commit and re-building?

I don't expect it to affect this, but since we have no other leads, I
suppose you may as well try it.  You would probably need to revert [1:
e1f6e3127a] first.

[1: e1f6e3127a]: 2017-09-29 18:40:06 -0400
  Bring back the busy wait after x_make_frame_visible (Bug#25521)
  https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=e1f6e3127a292e6ba66d27c49ddda4fe949569f5

bug#29518: 27.0.50; Compilation errors grab frame focus

[Eric Abrahamsen]

On 01/06/18 15:31 PM, Noam Postavsky wrote:
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> Thanks for the test! That triggers the same focus-grabbing behavior for
>> me -- from other Emacs frames, and other applications' frames, using
>> "emacs -Q".
>>
>> You tried this also with switching to a different workspace? And it
>> didn't turn the workspace's tab red?
>
> I tried now switching to a different workspace after starting the
> compile, the tab did not turn red.
>
>> Perhaps something's configured differently on my system (though I don't
>> know why it would be, I didn't customize anything). Is there anything I
>> might be looking for in config.log?
>
> I can't think of anything.  If you M-x debug-on-error RET x-focus-frame
> RET do you get any hits?

Sorry about the slow response...

That was an odd recipe, but turning on debug-on-error, then running
several varieties of (x-focus-frame (window-frame)), including focusing
the current frame or other frames, never did anything other than what I
would expect it to -- returning nil when the frame was already focused,
and focusing the frame when it wasn't.

>>> There have been some changes to the way timeouts are handles, which
>>> could affect frame/focusing stuff (see #24091, #25521, and #29095), but
>>> I don't think it should cause what you are seeing.
>>
>> I fooled with `x-wait-for-event-timeout' but that didn't do anything. I
>> suppose 6a788d2fc18c23dcfc5d0352649b2f690e9cbff7 could be related
>> (FRAME_VISIBLE_P certainly sounds relevant) but I don't actually
>> understand what's happening in there. Should I try just reverting the
>> commit and re-building?
>
> I don't expect it to affect this, but since we have no other leads, I
> suppose you may as well try it.  You would probably need to revert [1:
> e1f6e3127a] first.
>
> [1: e1f6e3127a]: 2017-09-29 18:40:06 -0400
>   Bring back the busy wait after x_make_frame_visible (Bug#25521)
>   https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=e1f6e3127a292e6ba66d27c49ddda4fe949569f5

I wasn't able to revert those commits cleanly, and I guess I don't
really think that's the issue. I suspect this is a change in X behavior
(Arch has xorg-server 1.19), and maybe it's not worth chasing after at
this point. Maybe it's enough just to leave this report hanging here,
and see if anyone else runs into it?

Eric

bug#29518: 27.0.50; Compilation errors grab frame focus

[Noam Postavsky]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> On 01/06/18 15:31 PM, Noam Postavsky wrote:
>> I can't think of anything.  If you M-x debug-on-error RET x-focus-frame
>> RET do you get any hits?
>
> Sorry about the slow response...
>
> That was an odd recipe, but turning on debug-on-error, then running
> several varieties of (x-focus-frame (window-frame)), including focusing
> the current frame or other frames, never did anything other than what I
> would expect it to -- returning nil when the frame was already focused,
> and focusing the frame when it wasn't.

Oh, it's odd because I made a thinko, that should have been M-x
debug-on-entry ...
         ^^^^^

> I wasn't able to revert those commits cleanly, and I guess I don't
> really think that's the issue. I suspect this is a change in X behavior
> (Arch has xorg-server 1.19), and maybe it's not worth chasing after at
> this point. Maybe it's enough just to leave this report hanging here,
> and see if anyone else runs into it?

Hmm, I guess.

bug#29518: 27.0.50; Compilation errors grab frame focus

[Eric Abrahamsen]

On 01/15/18 07:07 AM, Noam Postavsky wrote:
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> On 01/06/18 15:31 PM, Noam Postavsky wrote:
>>> I can't think of anything.  If you M-x debug-on-error RET x-focus-frame
>>> RET do you get any hits?
>>
>> Sorry about the slow response...
>>
>> That was an odd recipe, but turning on debug-on-error, then running
>> several varieties of (x-focus-frame (window-frame)), including focusing
>> the current frame or other frames, never did anything other than what I
>> would expect it to -- returning nil when the frame was already focused,
>> and focusing the frame when it wasn't.
>
> Oh, it's odd because I made a thinko, that should have been M-x
> debug-on-entry ...
>          ^^^^^

Aha! Turning that on results in nothing happening -- re-running your
earlier recipe for compile/install errors still yanks focus, but does
not enter the debugger. Other frame-switching activity (eg
`helm-projectile-switch-to-buffer') does enter the debugger.

Weird.

Eric

bug#29518: 27.0.50; Compilation errors grab frame focus

[Lars Ingebrigtsen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Aha! Turning that on results in nothing happening -- re-running your
> earlier recipe for compile/install errors still yanks focus, but does
> not enter the debugger. Other frame-switching activity (eg
> `helm-projectile-switch-to-buffer') does enter the debugger.

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

Are you still seeing this behaviour in recent Emacs versions?

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

bug#29518: 27.0.50; Compilation errors grab frame focus

[Eric Abrahamsen]

On 01/23/22 16:51 PM, Lars Ingebrigtsen wrote:
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> Aha! Turning that on results in nothing happening -- re-running your
>> earlier recipe for compile/install errors still yanks focus, but does
>> not enter the debugger. Other frame-switching activity (eg
>> `helm-projectile-switch-to-buffer') does enter the debugger.
>
> (I'm going through old bug reports that unfortunately weren't resolved
> at the time.)
>
> Are you still seeing this behaviour in recent Emacs versions?

I'm not! Feel free to close.

bug#29518: 27.0.50; Compilation errors grab frame focus

[Lars Ingebrigtsen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

>> Are you still seeing this behaviour in recent Emacs versions?
>
> I'm not! Feel free to close.

OK; done.

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