hammerspoon: hs.window.filter.defaultCurrentSpace:getWindows() sometimes missing some windows
Since the update to 0.9.79 (and still on 0.9.80) I’ve noticed visible windows on the current space sometimes not appearing in the results of hs.window.filter.defaultCurrentSpace:getWindows(). I managed to reproduce this consistently by:
- Going to a new space and opening the hammerspoon console:
> hs.inspect(hs.window.filter.defaultCurrentSpace:getWindows())
{ <userdata 1> -- hs.window: Hammerspoon Console (0x6000017f2cf8) }
- Opening System Preferences (or any other app, doesn’t seem to matter as long as it’s not already open) via Spotlight. Hammerspoon console throws:
2020-09-27 19:38:22: 19:38:22 ERROR: LuaSkin: Unable to fetch element attribute NSAccessibilityFrontmostAttribute for: System Preferences
Relevant?
- Now I can see the preferences window, but it doesn’t appear in
getWindows:
> hs.inspect(hs.window.filter.defaultCurrentSpace:getWindows())
{ <userdata 1> -- hs.window: Hammerspoon Console (0x6000017f2cf8) }
- If I change away from this space and back again, it’s now there:
> hs.inspect(hs.window.filter.defaultCurrentSpace:getWindows())
{ <userdata 1> -- hs.window: Hammerspoon Console (0x6000017f2cf8), <userdata 2> -- hs.window: System Preferences (0x600001626078) }
I can’t reproduce this on 0.9.78.
About this issue
- Original URL
- State: open
- Created 4 years ago
- Comments: 19 (11 by maintainers)
Oops… I read that bit then forgot it.
With
app:focusedWindow(), Hammerspoon restarts fine and my problem is solved.I restarted Kitty and opened six windows, and they all registered. I did this three times to make sure, and it worked every time.
I then reverted the change, restarted Kitty, and opened six windows. None of the windows registered. I did this three times also, and it failed all three times.
So this seems like a good fix.
@eraserhd did you use
if watcher:focusedWindow() thenorif app:focusedWindow() then? The latter is correct see https://github.com/Hammerspoon/hammerspoon/issues/2524#issuecomment-720647327Just making sure because the fix is working for me (and @callum-oakley, apparently).
@asmagill sorry for jumping on the bandwagon, but I just tried the change above and it fixed my issue #2580 so looks like that is the right track for sure 👍
FYI I haven’t forgotten about this, I’m just not certain how to fix it yet… apparently the expected accessibility attributes don’t get created immediately when an application is launched… there is a delay which our application launch watcher is now faster than so when
hs.window.filterchecks for the windows of a newly launched app, it is checking too early… I’m going to try and take a look at this again this weekend and see if I can some up with some ideas… I don’t want to put in artificial delays because tweaking the timing is a pain, it’s never consistent across machines/macOS versions, and delays things when it’s not necessary; but maybe there is some state or notification we can monitor that will tell us when the app is ready to be queried… not sure yet.