hs.window.animationDuration regression?

[luckman212]

• hs 0.9.93 (6148)
• macOS 12.1
• M1 MacMini

All of a sudden my window moves are not honoring the hs.window.animationDuration = 0.05 that I've been using for ages. Nothing has changed in my configs. The setFrame animation is taking roughly ~1s.

I've rebooted, and also tried disabling/re-enabling Accessibility permissions. Not sure what happened... anything I can check or try?

Thanks

[luckman212]

Just want to add this: setting e.g. hs.window.animationDuration = 10 does cause the windows to move verrrry slowly, so the function is not completely ignoring the setting. Just that 0 or short values like 0.05 aren't working as expected.

[cmsj]

If you set it to 0, do the animations happen instantly?

[luckman212]

No, they still take around 0.75~1s.

edit: I tried reverting back to 0.9.91 just to test, and the animations were also slow. So, it's something else. I wonder if Monterey 12.1 broke something? Anyone else having this problem?

edit 2: I did a simple test, to rule out a problem with my lua module.

from HS console:

hs.window.focusedWindow():move({x=150, y=150, w=700, h=700}, nil, true, 0)

• first time: the window resizes but does not change {top,left} position.
• running same command a 2nd time does move the {top,left}
• the resize happens slowly (ignoring the 0 duration)

[luckman212]

update 3: gets weirder. I thought I'd try creating a fresh user account to test with. Lo and behold, no problem there. Windows move / snap instantly. So there must be a per-user setting somewhere that's gotten out of whack in my main account. Something Accessibility-related I'm guessing. But no idea what that could be...

[jameslittle230]

I'm also experiencing this!

[luckman212]

Glad I'm not the only one. I can't figure this one out. Trying to compile a debug build from the source but running into some problems with the build script. Will post separately on that.

update: see #3043

[jameslittle230]

I don't think it's a macOS 12.1 regression -- I'm on 12.0.1.

[luckman212]

Agreed. As I pointed out in my earler comment: when I created a brand new test user account and ran HS inside of it, the windows were moving/resizing normally. So it's some user setting somewhere. I monkeyed around for a few hours trying to find out which one, and failed.

[luckman212]

@jameslittle230 Happy holidays🎄

Did you figure this out by any chance? It has me stumped. I've tried tossing various .plist files, clearing OS caches, rebuilding the app from source—even reinstalled the OS (!) but so far nothing has worked. Works fine from a fresh user account, so it's something in $HOME ... but no idea what!

I checked everything reported by sudo lsof -p $(pgrep -f 'Hammerspoon$') | grep -E 'REG.*/(Users|private)' | awk '{print $9}' but it doesn't appear to be anything in there.

[luckman212]

Another data point:

Using the OS-native Move Window to Left/Right Side of Screen function is instantaneous.

I collected various "window animation" related settings from around the web and assembled them into this script for testing. But, even when turning all those tweaks on (or deleting them), macOS did not give 2 "ducks"🦆 and continued to disobey.

Not sure what voodoo is at work here.

[jameslittle230]

@luckman212 - you were working on compiling the project, right? Did you ever figure out if this is a hammerspoon project regression? In other words, if you compile a previous version, does it still exhibit this smooth resize behavior?

[luckman212]

I haven't compiled an old version, but I did compile the latest code (no change) as well as try the 0.9.91 and 0.9.92 releases. No luck. Again- starting from a fresh user account it seems to work fine.

I just need to narrow down which of these 9,521 prefs is causing it. 😳

$ find ~ -type f -name "*.plist" | wc -l
    9521

[luckman212]

@jameslittle230 and @cmsj Happy new year! 🎉

I think I may have found the root cause (and a temporary workaround) for the slow window animations. It seems to be related to the following setting from Accessibility → Zoom → Advanced → Follow Focus → Follow keyboard focus.

On my system, anything except Never results in the animations slowing down:

You can try disabling that via the GUI or using this Terminal command:

defaults write com.apple.universalaccess closeViewZoomFocusFollowModeKey -int 0

N.B. you must log out and back in for that change to take effect.

Please give it try & let me know if your animations are snappy again.

[jameslittle230]

My Follow Keyboard Focus was set to Never just now when I went to check, and I'm pretty sure it's been set to Never this whole time.

HOWEVER, I just reloaded my HS config for an unrelated reason and my window movements are immediate again! So I guess this resolved itself for me on its own? Very mysterious.

[luckman212]

@jameslittle230 Interesting! Another way I found that (temporarily) slows down the animations is this:

1. open System Preferences → Keyboard
2. switch to the Input Sources pane
3. enable the Show Input menu in menu bar checkbox
4. from the Keyboard menubar item, choose Show Keyboard Viewer

edit: here's a gist to help test this (replace your init.lua with this temporarily. It just opens the HS console at launch and randomly moves it around your screen).

When I do this, my animations get slow again until I log out and back in. Again, not sure what voodoo is going on deep in the Accessibility subsystem to cause this but—there it is. Perhaps this was something you did before?

related: #2794, #2316

[luckman212]

@cmsj Curious if you have any thoughts on this one? Should I file a bug with Apple or do you think this is somehow fixable in HS?

[MoonSoul88]

@jameslittle230
solved this way

Accessibility → Zoom

if check this option "animation delay" Occurs immediately.
option check out and Reboot!

[Rhys-T]

This sounds like it's probably a result of the AXEnhancedUserInterface property getting enabled. AXEnhancedUserInterface is an undocumented property that was originally set to indicate that VoiceOver was running, but some third-party apps - including Grammarly and 1Password - also set it to true, to make sure that they can see inside Chrome and related apps. Other macOS accessibility features, like the Keyboard Viewer, also seem to set it.

Unfortunately, it has some weird side effects, like adding animations when you try to move/resize anything through the Accessibility API - and canceling those animations halfway through if you try to do a move immediately followed by a resize. See #3224 (comment) and replies for more info and workarounds.