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