GetPropertyReply[_NET_WM_NAME] failed

[powellnorma]

Sometimes, when no window is focussed, I get:

[..]
[2024-10-05 13:55:09.306377 ERROR watchers::watchers] Error on active window iteration: GetPropertyReply[_NET_WM_NAME] failed
[2024-10-05 13:55:10.307708 ERROR watchers::watchers] Error on active window iteration: GetPropertyReply[_NET_WM_NAME] failed
[2024-10-05 13:55:11.309513 ERROR watchers::watchers] Error on active window iteration: GetPropertyReply[_NET_WM_NAME] failed
[2024-10-05 13:55:12.310813 ERROR watchers::watchers] Error on active window iteration: GetPropertyReply[_NET_WM_NAME] failed
[2024-10-05 13:55:15.319081 ERROR watchers::watchers] Error on active window iteration: GetPropertyReply[_NET_WM_NAME] failed

It looks like AFK detection is also impacted by this (since IG this throws an exception, thus no heartbeat is sent at all, during that timeframe)

$ sleep 1; xprop -root _NET_ACTIVE_WINDOW
_NET_ACTIVE_WINDOW(WINDOW): window id # 0x0

awatcher/watchers/src/watchers/x11_connection.rs

Lines 125 to 131 in a045780

	let active_window = self.get_property(
	self.screen_root,
	net_active_window,
	"_NET_ACTIVE_WINDOW",
	window,
	1,
	)?;

It is reproducible on i3wm.

Here a screenshot showing that AFK Detection is not working correctly:

Hm, though here it looks like AFK Watcher and Window-Title Watcher are running seperatly:

awatcher/src/main.rs

Lines 57 to 58 in a045780

	let idle_future = run_first_supported(Arc::clone(&client), &WatcherType::Idle);
	let active_window_future = run_first_supported(Arc::clone(&client), &WatcherType::ActiveWindow);

I have changed the idle timeout to 5s, and now see:

[2024-10-05 14:31:56.602971 DEBUG watchers::watchers::idle] Idle again
[2024-10-05 14:31:56.602985 DEBUG watchers::report_client] Reporting as changed to idle for 5 seconds since 2024-10-05 14:31:51
[2024-10-05 14:31:56.603478 ERROR watchers::watchers] Error on idle iteration: Failed to send heartbeat

In the verbose server (aw-server-rust) logs I see:

[2024-10-05 16:34:36][INFO][rocket::server]: POST //api/0/buckets/aw-watcher-afk_hostname/heartbeat?pulsetime=10 application/json:
[2024-10-05 16:34:36][INFO][rocket::server::_]: Matched: (bucket_events_heartbeat) POST /api/0/buckets/<bucket_id>/heartbeat?<pulsetime> application/json
[2024-10-05 16:34:36][DEBUG][aw_transform::heartbeat]: Can't merge, data is different
[2024-10-05 16:34:36][DEBUG][aw_datastore::datastore]: Failed to merge heartbeat
[2024-10-05 16:34:36][INFO][rocket::server::_]: Outcome: Success(200 OK)
[2024-10-05 16:34:36][DEBUG][rocket::server]: sending response: Response {
    status: 200,
    version: HTTP/1.1,
    headers: {
        "content-type": "application/json",
        "server": "Rocket",
        "permissions-policy": "interest-cohort=()",
        "x-frame-options": "SAMEORIGIN",
        "x-content-type-options": "nosniff",
        "content-length": "96",
    },
    body: Body(
        Streaming,
    ),
}

Ok, I have found another thing that might contribute to the above screenshot: XScreenSaver idle time gets reset periodically every 30s, probably through Chromium:

https://unix.stackexchange.com/q/460175

[2024-10-05 14:45:23.549001 DEBUG watchers::watchers::idle] No longer idle
[2024-10-05 14:45:53.557848 DEBUG watchers::watchers::idle] No longer idle
[2024-10-05 14:46:23.565980 DEBUG watchers::watchers::idle] No longer idle
[2024-10-05 14:46:53.574329 DEBUG watchers::watchers::idle] No longer idle
[2024-10-05 14:47:23.582646 DEBUG watchers::watchers::idle] No longer idle

So when the idle-time is set to 180 (the default) that is never reached. I believe the only solution (apart from fixing Chromium) for this is to use actual mouse/keyboard activity for detecting AFK state

[powellnorma]

This also seems to happen for xfce:
https://github.com/ActivityWatch/aw-watcher-window/blob/7a89db41f36abe44a157e5a1fdeb572a60a4e2f9/aw_watcher_window/xlib.py#L59

I think it would be preferable to log "none" instead of just nothing. Otherwise it's not clear if the watcher was not running, or there actually was just no current window

Implemented the latter in 9daebc8