Hammerspoon: hs.window.filter.defaultCurrentSpace:getWindows() sometimes missing some windows

[callum-oakley]

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:

1. Going to a new space and opening the hammerspoon console:

> hs.inspect(hs.window.filter.defaultCurrentSpace:getWindows())
{ <userdata 1> -- hs.window: Hammerspoon Console (0x6000017f2cf8) }

1. 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?

1. 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) }

1. 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.

[asmagill]

I am unable to replicate this behavior. Are you still seeing it with 0.9.81?

[callum-oakley]

Unfortunately yes 😞 anything I can do to help debug?

Also I think the LuaSkin Accessibility error was a red herring, I don't have it any more on 0.9.81 and after removing and re-adding accessibility permissions (not sure which fixed it), but I still have the missing windows in getWindows.

I haven't looked much in to the code to see how hs.window.filter works, but it feels like an event is being missed somewhere when the new Preferences window first appears, because after doing pretty much any interaction (clicking on it and off it again, changing workspaces, etc) it then does appear in the list.

[callum-oakley]

Screenshots:

On 0.9.78 preferences appears in the list immediately:

[asmagill]

Ok, about every 5th try or so I can finally replicate this... hmmm... that's going to be annoying to try and track down.

[asmagill]

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.filter checks 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.

[callum-oakley]

Ah interesting, thanks for the update. Sounds like a pain!

Let me know if you want me to run any kind of tests / debug builds / etc on my machine so you have more samples to work from.

One other thing probably worth mentioning for my specific use case: I only use the window.filter to query for currently visible windows when I need them (for a custom window switcher), I'm not subscribing to updates or anything. That means this wouldn't be an issue for me if I could manually trigger a state refresh. Is there some way to manually recompute the list of visible windows on demand?

[asmagill]

@callum-oakley I'd like you to try something:

Open up the hs.window.filter lua file in a text editor (it will be located inside the Hammerspoon application package, most likely at /Applications/Hammerspoon.app/Contents/Resources/extensions/hs/window/filter.lua, unless you installed Hammerspoon in a different location).

Change line 1429 from:

~lua
if watcher:pid() then
~

to:

~lua
if watcher:focusedWindow() then
~

Then restart Hammerspoon and see if that helps at all. We had to tweak that line when 0.9.81 came out because of changes to hs.uielement, but at the time I was more concerned with getting it load and run without throwing an error. Looking closer at what it was originally put in place to do, I realized that the rewrite of hs.uielement made monitoring for the pid property to be updated useless -- it's now being captured before the application watcher even notifies Hammerspoon that the app has launched... a better check is for the initial window.

Of course this will probably mis-identify a regular (i.e. not background) application that doesn't create a window when it first starts, but (a) that's not the usual pattern for macOS apps, and (b) if this fixes your immediate issue, it confirms I'm on the right track and I'll keep looking for something to handle the outliers.

[asmagill]

Sorry, my bad, make line 1429 read if app:focusedWindow() then

[luckman212]

@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 👍

[callum-oakley]

@asmagill That works for me! 🎉

[eraserhd]

I'm on 0.9.81, and if I change line that line (now line 1427), I get:

2020-11-06 10:01:47: *** ERROR: ...n.app/Contents/Resources/extensions/hs/window/filter.lua:1427: attempt to call a nil value (method 'focusedWindow')
stack traceback:
    ...n.app/Contents/Resources/extensions/hs/window/filter.lua:1427: in upvalue 'startAppWatcher'
    ...n.app/Contents/Resources/extensions/hs/window/filter.lua:1556: in upvalue 'startGlobalWatcher'
    ...n.app/Contents/Resources/extensions/hs/window/filter.lua:1721: in upvalue 'start'
    ...n.app/Contents/Resources/extensions/hs/window/filter.lua:1912: in method 'subscribe'
    .../jfelice/.hammerspoon/Spoons/WindowSigils.spoon/init.lua:147: in function 'WindowSigils.start'
    /Users/jfelice/.hammerspoon/init.lua:76: in main chunk
    [C]: in function 'xpcall'
    ...app/Contents/Resources/extensions/hs/_coresetup/init.lua:702: in function 'hs._coresetup.setup'
    (...tail calls...)

My window filter is also missing windows. I think if I use my custom spoon long enough (which decorates every window with a letter), eventually all the windows get registered, but after reloading my config, some new kitty windows get ignored.

[luckman212]

@eraserhd did you use if watcher:focusedWindow() then or if app:focusedWindow() then ? The latter is correct see https://github.com/Hammerspoon/hammerspoon/issues/2524#issuecomment-720647327

Just making sure because the fix is working for me (and @callum-oakley, apparently).

[eraserhd]

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.

[asmagill]

Just an FYI -- I have noticed that an application that starts with absolutely no windows but creates one later is, as I suspected, initially missed, though as noted above, if you wait long enough, they will eventually be captured as well.

I think I understand filter enough now to add a fix, and hope to do so this weekend -- I'll post when I have it uploaded to get everyone's input.

Glad to hear that this initial fix seems to be helping!

[callum-oakley]

Noted. Thanks so much for the help with this @asmagill, I can't overstate how much I've come to depend on Hammerspoon to make macOS a nice environment to work in. It's such a brilliant tool. :)

[luckman212]

Yes, thank you @asmagill !

[luckman212]

Should this be merged with #2580 ?

[asmagill]

2576 should now work with apps that don't open a window at launch, but are able to create and present them later.