[SOLVED] focus stealing by xterm/tmux in Slackware -current

since i installed Slackware -current (a year ago) i have this problem of focus stealing by one single xterm window inside a fvwm session. i ssh from that xterm window to my main server where i connect to a tmux session. within tmux i run various applications from which one seems to be associated with this focus stealing problem, that is actions or activities (messages and such) within the alpine mail client.

you can imagine that this is a very annoying problem : you type in any window and suddenly the focus falls on that xterm/tmux window with unpleasant consequences, depending on which pane or window is active within tmux, that need to be un-done somehow.

now, the chain is long, and i don't know who is the culprit : tmux, xterm, fvwm or alpine - decreasing in that order ? but this problem surfaced after the Slack-Current installation on the local machine, so that would again point it on fvwm or xterm ? who can help ?

I know xterm has some control-sequences for letting an application know whether it gains/loses focus, but I'm not aware of any that let it grab focus (which is generally frowned upon by X11 application guidelines).

alpine/tmux shouldn't be able to interact with anything outside of their tty/the terminal window. What they can do is issue a ^G (bell character) and depending on how xterm is configured that can be interpreted as a signal to set the "Urgency" hint on the window, which in turn a window manager can act on depending on its own configuration and default behaviours. Maybe something in your fvwm config is set to focus windows going into an 'Urgent' state, but it doesn't happen here with my fvwm config (which is a modified version of the one shipped with slackware), and bellIsUrgent defaults to false in xterm anyway, so that would mean there are two non-default values that would need to be set for this to be the reason.

Kind of clutching at straws here, can't think of any other possible explanation. I'll be interested to hear what it is if you manage to track it down.

Well when in doubt check the man page.

And lo ... it turns out there ARE control sequences for window ordering: https://invisible-island.net/xterm/c...s;Ps;Ps-t.1EB0 (wtf?).

/etc/X11/app-defaults/XTerm contains these lines but it seems to be disabled by default anyway:

! Depending on your environment, you may wish to disable those by default by
! uncommenting one or more of the resource settings below:
!*allowFontOps: false
!*allowTcapOps: false
!*allowTitleOps: false
!*allowWindowOps: false

If it's enabled somehow it's probably that plus a window manager setting that causes it to grab focus, I haven't used fvwm for about 25 years so I can't help there. These are also in the Ctrl-RMB menu at the bottom.

Or it could just be the bell (\b, 0x07) and the window manager as already hypothesised. This resource seems related - and should also be off by default - https://invisible-island.net/xterm/m...rces:popOnBell This and some other bell related options are in the Ctrl-MMB about half way down.

There also seems to be a lot of tmux options related to bells and monitoring term clients.

thank you for your suggestions ! regarding the beep or C-g, i will try to stop that in Alpine by enabling :

[x]  Suppress Status Message Beeping

here the related Alpine help :

This feature affects Alpine's behavior when it displays status message (e.g., Error complaints, New mail warnings, etc). Setting this feature will not affect the display of such messages, but will cause those that emit a beep to become silent.

let's hope that will do it. as said i experience this issue just on that one single machine with a one-year-old Slack-Current installation but interestingly nowhere else where i run the Slackware/fvwm and this ssh/tmux/alpine scenario. i will return to that problem machine tonight and will see if the situation improved. will keep you posted...

thank you for your suggestions ! regarding the beep or C-g, i will try to stop that in Alpine by enabling :

[x]  Suppress Status Message Beeping

here the related Alpine help :

This feature affects Alpine's behavior when it displays status message (e.g., Error complaints, New mail warnings, etc). Setting this feature will not affect the display of such messages, but will cause those that emit a beep to become silent.

let's hope that will do it. as said i experience this issue just on that one single machine with a one-year-old Slack-Current installation but interestingly nowhere else where i run the Slackware/fvwm and this ssh/tmux/alpine scenario. i will return to that problem machine tonight and will see if the situation improved. will keep you posted...

quelling the Alpine beep did it - no more grabbing, no more stealing of the window focus ! thank you for your suggestions. marking this solved...

Just to correct a comment I made above, seems Slackware's xterm does indeed have bellIsUrgent set 'true' by default in its app-defaults file — I was on my CRUX system when I posted so couldn't check, but I should have done so before posting.

And fvwm does have a built-in function that responds to the urgency hint as follows:

DestroyFunc UrgencyFunc
AddToFunc UrgencyFunc
+ I Iconify off
+ I FlipFocus
+ I Raise
+ I WarpToWindow 5p 5p

So, this one seems to be fully explained now.

Finally, a small nit-pick of notzed post: bell is \a not \b (which is backspace), but everything else he said is otherwise correct.

thank you for all this information, one never stops learning...!

the funny part here is that i use an ~/.fvwmrc file i had created perhaps some two decades ago. it practically never changed over the years except for minimal necessary adjustments. originally i had created it for fvwm v1, and i am with every upgrade surprised that this old RC file continues working with the newest fvwm versions. the new ones look entirely different. there is for example no UrgencyFunc in my old fvwmrc file though it was perhaps called differently at that time.

i speculate here that with that OS upgrade to -Current on my local machine a year ago something changed for XTERM or FVWM locally because TMUX/ALPINE reside remotely on the server and were surely not affected by this upgrade.

in any case, i leave it as it is. the issue was stopped within Alpine, while we leave this way this UrgencyFunc axis operational.

The defaults for XTerm did change at some point during this current development cycle. The main change was from the default black on white, to something that more closely reflects the look of the linux virtual console, but it looks like the Urgency hint setting came along for the ride.