windowfilter.focusWindow* methods hang for ~10s
snarfed opened this issue · comments
Hi! First off, thank you all for building and maintaining Hammerspon. It's great! I couldn't live without it.
I've been happily using v0.9.100 with the same unchanged config for a while now. Sometime in the past few days, the windowfilter focusWindow* methods started hanging for 5-10s every time they're called. I'm not sure what suddenly triggered this, but my best guess is that I upgraded to macOS 14.1.2 (23B92) from 14.1.1.
Specifically, this in the console reproduces the hang for me most times I run it and there's a window to the east:
hs.window.filter.default:focusWindowEast(nil, true, true)Doesn't seem to be CPU or memory, Hammerspoon's memory footprint is only 20-30MB when this happens, and it's not busy-waiting, it's at <1% CPU usage throughout the hang. I assume it's waiting on I/O from something, but I don't know what. Are there any known issues with macOS 14.1.2? Could any window configuration or apps I have open cause this?
Thank you in advance!
If you open the Hammerspoon console and run:
hs.window._timed_allWindows()
you'll almost certainly see that one application is taking multiple seconds to respond. Either one of your apps added a new helper which doesn't implement accessibility APIs, or one of your apps has gotten internally stuck and has stopped responding to accessibility calls. The latter is a thing that happens from time to time and either restarting that app, or rebooting, clear it up.
Ah, interesting! Thanks for the tip. This is what I see when I run it a couple times in a row, and then again many hours later:
> hs.window._timed_allWindows()
2023-12-23 08:34:42: took 0.09s for com.apple.quicklook.QuickLookUIService
2023-12-23 08:34:42: took 12.01s for com.apple.WebKit.WebContent
2023-12-23 08:34:42: took 0.06s for N/A
2023-12-23 08:34:42: took 0.09s for com.apple.ViewBridgeAuxiliary
2023-12-23 08:34:42: took 0.05s for com.apple.PressAndHold
table: 0x600002d6d140
> hs.window._timed_allWindows()
2023-12-23 08:35:05: took 12.01s for com.apple.WebKit.WebContent
table: 0x600002d6c040
> hs.window._timed_allWindows()
2023-12-23 17:39:09: took 12.01s for com.apple.WebKit.WebContent
table: 0x600002c931c0
I don't use Safari, so I'm guessing com.apple.WebKit.WebContent is some Electron or similar webview-wrapped app? Also suspicious that it takes exactly 12.01s every time.
I tried rebooting yesterday, and that fixed it for a few minutes but then it started hanging again. I'll try again now.
Turns out rebooting doesn't fix it after all. I've tried twice now, and it still happens immediately on startup. I may have misremembered it working for a few minutes the first time I tried.
Any other debugging ideas?
Huh, that's really odd, we're supposed to ignore WebContent because it's known to respond slowly: https://github.com/Hammerspoon/hammerspoon/blob/master/extensions/window/window.lua#L85