hs.window:moveToScreen() behaves weirdly in macOS 12.4 when applied to a Google Chrome window.

[liancheng]

After upgrading to macOS 12.4 Monterey, I've noticed two issues:

1. While moving a Google Chrome window using the moveAndResize function in the WinWin Spoon, the target window shows an animation while moving/resizing. Windows of other applications do not behave like this: they just immediately resize/move to the required shape and location.
2. While moving a Google Chrome window to another screen using moveToScreen() in WinWin, instead of moving to the target screen, the target window shrinks to roughly half of the original length and width. Same as above, windows of other applications show the desired behavior.

Further debugging showed that calling hs.window:moveToScreen() directly shares the same issue.

You may reproduce this issue by opening a Google Chrome window, navigate to https://www.hammerspoon.org/docs/hs.window.html, and run the following snippet in the Hammerspoon console:

c = hs.window.find("Hammerspoon docs: hs.window")
s = c:screen()
c:moveToScreen(s:next())

Version information:

• macOS: 12.4
• Hammerspoon: 0.9.97 (6267)
• Google Chrome: 101.0.4951.64 (Official Build) (x86_64)

[dasmurphy]

I did not use that function for my code, since i wrote some on my own...

Here is an excerpt from my code. I found some things from that online and derived this from it.

local function initWindowValues()
	local win = hs.window.focusedWindow()
	local f = win:frame()
	local screen = win:screen()
	local max = screen:frame()
	return win, f, screen, max
end

hs.hotkey.bind({"cmd", "alt", "ctrl"}, "/", function ()
	local win, f, screen = initWindowValues()
	local screens = hs.screen.allScreens()
	local i = 0
	local screenNo = 0
	for i = 1, #screens do
		if screens[i]:id()==screen:id() then
			screenNo = i
		end
	end
	local newScreenNo = screenNo+1
	if newScreenNo>#screens then
		newScreenNo = 1
	end
	win:moveToScreen(screens[newScreenNo])
end)

May be this helps you a little bit to fix that function stuff.

[zackfern]

While moving a Google Chrome window using the moveAndResize function in the WinWin Spoon, the target window shows an animation while moving/resizing. Windows of other applications do not behave like this: they just immediately resize/move to the required shape and location.

I've recently observed the same thing happening with Firefox (101.0) on macOS 12.4 and Hammerspoon 0.9.97 (6267), but I'm using hs.window:setFrame. I recently upgraded to 1Password 8 around the same time I noticed this happening. I've realized that when I restart Firefox and don't use 1password autofill in the new session, my resizing behaves as expected (instantly, correctly, no animation). But once I use autofill the window movements animate and sometimes require multiple attempts to reach their correct size and location.

So out of curiosity, are you also using 1password 8 with the new Universal Autofill feature? If so, we might be seeing the same issue related to it. If not, sorry for the tangent on your thread. 😄

[BrianHicks]

That's exactly my situation too. 1PW 8, Chrome, latest macOS. I think you're on to something here.

[MuhammedZakir]

Maybe related: pqrs-org/Karabiner-Elements#3075 (comment). Weirdly, the comment mentions the problem being solved after upgrading to macOS 12.4.

[asmagill]

FWIW, I see the same behavior with Safari and 1password with Universal Autofill... and I'm already running 12.4, so...

Not sure what's up, but I'll check out the 1password forums later today and submit a bug report if it's not already known. I'm pretty sure it's not anything Hammerspoon is doing, so it's either a macOS change/bug that we're not aware of or an issue with 1password and how it's tapping into things for the autofill support.

[mkosma]

I'm having this issue, and I'm also a 1Password user.

• Today's 1Password update didn't make a difference.
• Closing the 1Password application then closing & relaunching Chrome seems to fix the behavior
• Disabling the 1Password Chrome extension then closing & relaunching Chrome also seems to fix the behavior

I tried a couple other combos inconclusively - it could be that, in some percentage of cases, closing and relaunching Chrome temporarily fixes the problem regardless of whether 1Password is involved.

[NDuggan]

Just adding another +1 for the weirdness @zackfern mentioned above. Only my browser window shows the animation and requires multiple attempts to move the window to the correct location.

App Versions

• Hammerspoon 0.9.97
• MacOS 12.4
• Firefox 101.1
• 1Password (8) for Mac 8.7.1

[danieldisu]

Another +1 here, happens in both chrome and edge and with 1password 7, not 8

App Versions

• Hammerspoon 0.9.97
• MacOS 12.3.1
• Chrome Version 102.0.5005.115
• Edge Version 102.0.1245.44
• 1Password (7) for Mac 7.9.5

[kassi]

Same issue here. I do have Karabiner Elements installed as well as 1password 8.
However the remappings I have defined in KE (mainly for switching tabs in Firefox) work as expected.

It's only that the shortcuts I created in hammerspoon to move windows fast to a desired position in a desired size don't work properly for Firefox. It's slow and often misplaced. Only a second hit moves it correctly (most of the times). I'm using setFrame.

• Hammerspoon 0.9.97
• MacOS 12.4
• Firefox 91.10.0esr (for whatever reason not getting a newer version from company software center)
• 1Password 8.7.1
• Karabiner Elements 14.4.0

[mkosma]

For me, this issue has been resolved. It was in fact an odd interaction between 1Password's MacOS app and Chrome plugin.

I worked on this with Paul from 1Password support, sending him here and explaining how to set up Hammerspoon and reproduce the issue. I installed a desktop app update on July 12th and haven't seen this problem since.

FWIW my 1Password for Mac reports version 8.9.0, 80900001 on BETA channel.

[liancheng]

Hmm, I'm not a 1Password user, but I'm using LastPass. I don't remember hitting this issue in Firefox, where LastPass is also installed. Also, after moving to an M1, I'm no longer able to reproduce this issue.

[holeyness]

I think this issue is now resolved.

[francoiscote]

I still have the issue.

• macOS 12.5
• Chrome 104.0.5112.79
• Hammerspoon 0.9.97
• 1Password Extension 2.3.7