bug#29518: 27.0.50; Compilation errors grab frame focus

[Noam Postavsky <npostavs@users.sourceforge.net>]

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