Possibly identified the cause of window moving/sizing issues (seems due to animation timing and using move/size independently)

[MarqueIV]

There seems to be an issue with setFrame, the grid-related functions and anything else related to window moving/sizing, and I think I've identified the issue as being related to the new os animations.

Specifically, it seems if you attempt to move/size a window while there's an existing animation, that action gets interrupted with the new call, thus the window isn't moved/sized correctly.

The hack I've come up with to get around this is rather than this....

window.setFrame(targetFrame)

I now do this...

window.setTopLeft({
    x=targetFrame.x,
    y=targetFrame.y
})

os.execute("sleep 0.25") -- Must be long enough to allow the move animation to complete.

window.setSize({
    w=targetFrame.w,
    h=targetFrame.h
})

where 0.25 seconds is usually enough to ensure the move animation happens completely before the resize operation. (You can reverse the order and you'll have the same effect.)

I've also seen cases where moves requiring longer distances equally require a longer time to animate, but the above seems to work for my particular use-case.

I'm somewhat confident this is the issue as when I reduce the delay, say down to 0.1 seconds (any value less than the needed animation), windows don't end up where they're supposed to be. It's also incredibly subtle if you're right at the limit of the animation as it can seem the sizing is only a few pixels off, when in reality, the correct values were set, it was just interrupted right before it was completely animated into place/size.

As I said, I have this workaround, but I'm not crazy about it as now there are essentially two animations that happen when moving/sizing windows, but at least they end up where they're supposed to be.

[MarqueIV]

Bueller? Bueller?

[minusfive]

Do you have an example of the issues you mention? Or perhaps can you share the code you're using? I use hs as my primary/only window manager and don't experience any issues, so curious. Perhaps there's something I can help spot?

[MarqueIV]

Can you try my above code without the delay and see if it moves as you expect? You need to make sure the window moves a long distance or else it will appear to work correctly.

For instance, if you have a 4K screen, place the window off the lower-right of your screen, basically as far from the upper-left corner as you can get it. Then use the move and size calls to move it to the upper left corner, maybe 1/8th the screen width and height. (It's even easier if you have multiple monitors.)

The point is it has to move a long-enough distance to make sure the animations from the first call are not yet completed when the second call starts. That's the issue, and why the pause 'fixes' it.

Lemme know if you can repro it that way.

[MarqueIV]

@minusfive, did you give it a try?

[minusfive]

@MarqueIV, no, sorry, I'm busy. But I did quickly record a video for you of things working fine for me with animation and without delay. I use a 5K screen (5125 x 2160):

Screen.Recording.2025-01-16.at.01.44.49.mov

You can peruse my custom WindowManager spoon here, in case it helps: https://github.com/minusfive/dotfiles/blob/main/.config/hammerspoon/Spoons/WindowManager.spoon/init.lua

Top level I'd suggest trying setFrameInScreenBounds instead of setFrame.

[MarqueIV]

Just watched your video. I can see that working fine because it's not doing the resizing which is what causes the actual problem. Your video looks like it's only doing moves. Can you change it so it's resizing from a quarter to a half or full screen to centered that kind of thing.

I'll also try out your spoon when I'm back in front of my computer.

[minusfive]

It is resizing, I’m just doing it too quickly.

[minusfive]

@MarqueIV here's a new video:

Screen.Recording.2025-01-16.at.10.00.35.mov

[minusfive]

@MarqueIV did that help?

[MarqueIV]

No, I'm still seeing the issue I mentioned. Not sure why/what's going on on my machine, but a few things... my animations aren't as fast as yours. Not sure if you tweaked your mac to reduce their times in user defaults. But secondly, again, when I call the move/resize via a keyboard shortcut and it has a long way to go, one of the two doesn't complete. I have to re-trigger it a second time. That is, unless I do what I said above... separate the move from the resize and put a delay between them long enough to account for the animation.

Any thoughts on why I'm seeing this and you're not? I can make a video showing this if you think it'll help, although it'll only reveal what I already explained.

[MarqueIV]

Not sure if this makes a difference, but can you try toggling quickly between quarters, halves, thirds, etc.? i.e. top-left, then bottom half, then top-right-third, then bottom left, etc. I do see yours are resizing, but only in one dimension. Not sure if moving and resizing in two dimensions is part of it.

Also, I have multiple monitors so my windows have a lot farther than yours do to get from one side to the other. (My desktop is 8960 wide by 4,124 high across them all.)

Another thing is HammerSpoon isn't respecting its own animation settings so maybe something there too has changed. No idea. Again, trying to think of any other things here that could be the cause. Really frustrating, although the workaround... well... works!

[minusfive]

Won't be able to reply for a few days, but vertical movement/resizing isn't problematic in my experience either. Will try and record at some point when I have a chance.

You can tweak the animation speed with https://www.hammerspoon.org/docs/hs.window.html#animationDuration

[jannis-baum]

I'm also having the issue with setFrame and all its variations (setFrameWithWorkarounds, setFrameInScreenBounds) not being able to resize and set position. The only way I was able to get it to work was first running setSize, then waiting 0.25s as @MarqueIV suggested, and then running setTopLeft; the other way around it also never does both. On top of this, setting hs.window.animationDuration = 0 does nothing, i.e. I'm stuck watching the 2 slow animations.

---

My exact use case for context: A function that resizes windows so they fit below SketchyBar on external screens, i.e. checking if the top window edge is in the top 32px of the screen, and if so moving the window down by the overlap and adjusting its height so the bottom edge stays in the same y-coordinate:

hs.window.animationDuration = 0 -- does nothing

local sketchybar_height = 32
local function fit_win_below_sketchybar(window)
    local screen = window:screen()
    -- ignore built-in display, fits because of notch
    if string.find(screen:name(), 'Built%-in') then
        return
    end
    local win_frame = window:frame()
    -- compute overlap with sketchybar
    local overlap = screen:frame().y + sketchybar_height - win_frame.y
    if overlap <= 0 then
        return
    end
    -- horrible hack to move & resize window
    -- https://github.com/Hammerspoon/hammerspoon/issues/3731
    window:setSize({ w = win_frame.w, h = win_frame.h - overlap })
    os.execute('sleep 0.25')
    window:setTopLeft({ x = win_frame.x, y = win_frame.y + overlap })
end

EDIT: Another probably relevant piece of information is that I mainly use this for windows that are the size of the screen, i.e. for a w*h-sized screen with the top-left at x0,y0, the window is at x0,y0 with size w*h before and should be at x0,y0+32 with size w*h-32 after calling the function. So the issue may be related to this "bottom stickiness".

EDIT 2: Just discovered that the behavior depends on the app. Everything I described above (including the inability to disable the animation) was about Firefox. For other apps (e.g. HS console window, Apple Mail, Apple Safari) there don't seem to be any problems.