Various focus issues

[ghost]

I've observed various problems with window focus order and keyboard input. I'm using the Debian package, which recently updated to a newer IceWM release from this repository. IceWM calls it "A new upstream snapshot (basically version 1.5.5 with fixes)"

At 1.4.3.0~pre-20181030-2 and maybe 1.5.5+git20190610-1 (I don't know yet):

• Sometimes (or often), a newly appearing window will not be rendered as focused, even though it's on top, and has keyboard focus
• Sometimes, the opposite happens, and it's rendered as focused and is on top, but the keyboard focus is on the window behind it.

At 1.5.5+git20190610-1 (new behavior):

• Sometimes closing a window does not return focus to the previous window, but some other window. Apart from "returning" to the wrong window, everything works correctly.

I suspect all these are connected.

My configuration (excluding some irrelevant parts anyway) in preferences:

Win95Keys = 1
TaskBarShowCPUStatus = 0
TaskBarShowMEMStatus = 0
TaskBarKeepBelow = 0 
TaskBarClockLeds = 0
TaskBarShowMailboxStatus = 0
EdgeResistance = 8
SnapDistance = 8
UseMouseWheel = 1
TaskBarShowWorkspaces = 1
MenuMouseTracking=1
FocusOnMapTransient=0
FocusOnMapTransientActive=1
PagerShowPreview=0

There's also a focus_mode file, not sure if it's used at all:

FocusMode=1

[gijsbers]

These are actually two different and unrelated issues. Could you give reproducable scenarios for the first? Does it also work in other focus modes, like Quiet Sloppy Focus?

[ghost]

I can now confirm that the first problem affects 1.5.5+git20190610-1 too. Is the second issue the same as #355?

I don't know a way to reproduce any of these issues. They seem to happen randomly. Sometimes they're fairly consistent. Right now, opening a new firefox window (via shortcut) often shows it defocused like in the first issue (but without keyboard focus; a third case I guess), unless I hit the shortcut while a newly created urxvt window is focused. Makes no sense to me.

[gijsbers]

The second is fixed. For the first there isn't enough information to work on it yet.

[ghost]

Is there anything I could do to debug this?

[gijsbers]

Yes, the best would be reproducibility. At least a sequence of actions leading up to the condition. Also try to reproduce on a clean account, or on a clean system, where clean means little or no adaptations or extra utilities which could interfere. Perhaps maybe monitor focus properties like WM_STATE, _WIN_STATE, _NET_WM_STATE on application windows and _NET_ACTIVE_WINDOW on the root window. Record time in milliseconds for changes on these properties.

[ghost]

I really can't come up with something reproducible. I guess it just depends on the current window order, but I have no idea what could trigger it.

How can I monitor said properties?

[gijsbers]

Here is one cheap trick, which you could add to the icewm keys file, but you want this information on both the focused window and the other window.

xprop -root _NET_ACTIVE_WINDOW | if read a b c d e; then echo "$(date +%T.%N) $a $b $c $d $e" && xprop -id $e _NET_WM_VISIBLE_NAME WM_HINTS WM_STATE _WIN_STATE _NET_WM_STATE ; fi

It may be a https://en.wikipedia.org/wiki/Race_condition, which is notoriously difficult to debug. You could go back to previous versions until it works fine. This would identify when it started. Sofar this is the first such report, which asks the question if it is specific to your system.

[ghost]

Starting firefox with a key binding, while hexchat was focused. Hexchat stayed focused and ekyboard input went to it in this case.

_NET_ACTIVE_WINDOW(WINDOW): window id # 0x14002ef
_NET_WM_VISIBLE_NAME(UTF8_STRING) = "HexChat"
WM_HINTS(WM_HINTS):
		Client accepts input or input focus: True
		Initial state is Normal State.
		bitmap id # to use for icon: 0x14002f2
		bitmap id # of mask for icon: 0x14002f3
		window id # of group leader: 0x1400001
WM_STATE(WM_STATE):
		window state: Normal
		icon window: 0x0
_WIN_STATE(CARDINAL) = 0, 1023
_NET_WM_STATE(ATOM) = _NET_WM_STATE_FOCUSED

_NET_WM_VISIBLE_NAME(UTF8_STRING) = "Mozilla Firefox"
WM_HINTS(WM_HINTS):
		Client accepts input or input focus: True
		Initial state is Normal State.
		bitmap id # to use for icon: 0x320012e
		bitmap id # of mask for icon: 0x3200134
		window id # of group leader: 0x3200001
WM_STATE(WM_STATE):
		window state: Normal
		icon window: 0x0
_WIN_STATE(CARDINAL) = 0, 1023
_NET_WM_STATE(ATOM) = _NET_WM_STATE_DEMANDS_ATTENTION

Nothing interesting here, I guess? _NET_WM_STATE_DEMANDS_ATTENTION is true, in some (all?) cases, the new window will flash around. I could have mentioned this before.

Omitted timestamps that your script snippet adds, since they were meaningless. I got the active window by using "sleep 10s" + part of your snippet, and the firefox window by switching to a terminal and manually calling xprop (without focusing the firefox window).

[gijsbers]

Good.

The DEMANDS_ATTENTION is quite relevant, as is Firefox, because it relates to bug #196. That bug I have observed too, but only with Firefox, not with other applications.

I can repeat this scenario: set focus to ClickFocus. Open hexchat on an empty screen. It has focus. Start Firefox by a key. It appears over the hexchat window, with DEMANDS_ATTENTION set and the task button flashing, but hexchat still has the input focus.

Should focus be given immediately to an application which creates a new window with DEMANDS_ATTENTION set if ClickFocus is on?

This appears to be a different issue than your first two bullet points of this issue. Those say that focus is not properly rendered.

[ghost]

Well, I observed this with a custom GTK app too. And it's definitely what I tried to report (except the second bullet seems to be unrelated). The least common denominator of my observations is that both the originally active window and the newly created window are both by GTK.

[gijsbers]

OK. Does the GTK also appear with DEMANDS_ATTENTION set?

[ghost]

Couldn't reproduce it with GTK yet. (It happened fairly often, just not over the course of the last 5 weeks.)

[ghost]

I finally caught GTK doing it again. The new window was not _NET_ACTIVE_WINDOW, but it had "_NET_WM_STATE(ATOM) = _NET_WM_STATE_DEMANDS_ATTENTION" set.

This is just a gtk window that's shown with gtk_widget_show_all() in reaction to keyboard input.

[gijsbers]

You could experiment by setting "FocusOnAppRaise=1" in your preferences. Is the new window related to the previous window in the sense that it has WM_TRANSIENT_FOR set or that WM_CLIENT_LEADER is the same?

[ghost]

WM_TRANSIENT_FOR was not set, WM_CLIENT_LEADER was the same.

[gijsbers]

@wm4 If you try this can you look for "focus urgent group member" messages in icewm output?

[ghost]

Where does icewm log to? Nothing in ~/.xsession-errors.

Edit: I guess I'll first need to rebuild icewm with above commit.

[gijsbers]

yes. If you press Cltr+Alt+space then you give a command like date to show where the output goes.

[gijsbers]

You could also set FocusOnMapTransient=1 in your preferences.