Maximization takes three steps for Chrome

[hasantahir]

As reported earlier in #2578, I notice that the Chrome app window takes three steps to maximize. For the rest of the apps, hs.window:maximize() works fine.

I have been using hs.window.focusedWindow():maximize() tied to the keyboard shortcut ⌘ + ⌥ + ⌃ + M to maximise the windows.

Below is a screencast of what I observed:

hammerspoon.mp4

Cheers

[francoiscote]

may be related to #3224 and #2316

[francoiscote]

see comments in the issues above. On my end this was caused by the Grammarly Desktop app. Quit it and restart Chrome.

[hasantahir]

Thanks for pointing to those comments. I tried to make sure all other apps were killed but got the same behaviour. Even in the incognito mode with all the extensions disabled, getting the same behaviour. Getting the same behaviour with Microsoft Edge. Firefox like other apps is working fine.

Also running Karabiner elements but suspecting it has something to do with Chromium-based browsers.

[dasmurphy]

This may help... I use this vor maximising windows.

function maximizeWindow()
	-- full screen window
	local win = hs.window.focusedWindow()
	local f = win:frame()
	local screen = win:screen()
	local max = screen:frame()

	f.x = max.x
	f.y = max.y
	f.w = max.w
	f.h = max.h
	win:setFrame(f,0)
end

[hasantahir]

Thanks @dasmurphy

Get the same issue with your routine. Everything except Chrome and Edge works fine.

[dasmurphy]

@hasantahir That is weird, since Chrome is working with this routine here fine.

[SethMilliken]

FWIW, I am experiencing these same symptoms (and not just for hs.window:maximize(), but also hs.window:moveToUnit() and hs.window:setFrameInScreenBounds()).

Edit: Removed lists of applications I observed to be affected and not affected, as this appears to be a red herring based on further experimentation.

I've found one reliable way to reproduce this issue. Turning on the Accessibility Keyboard appears to cause any application that becomes active while it is present to become poisoned with this sluggish window manipulation behavior (System Preferences -> Keyboard -> Viewer -> Enable Accessibility Keyboard or select the Accessibility Keyboard from the Accessibility Shortcuts menu icon if that is enabled).

Disable the Accessibility Keyboard, restart the poisoned apps, and window manipulation returns to normal.

From all of the issues I've read touching on this problem, it appears that the Accessibility Keyboard may be only one possible trigger for this behavior. That said, I have not been able to reproduce the issue with 1Password (8.9.4), the "Follow keyboard focus" accessibility feature, the "Use keyboard shortcuts to zoom" accessibility feature, or any other accessibility feature (I went through trying many of them).

I'm on macOS 12.6.

[Rhys-T]

Looks like this is probably an issue with the AXEnhancedUserInterface attribute. Full explanation and workaround posted here: #3224 (comment)

[UseK]

I get the same issue with following environment.

• Intel Mac 2019
• macOS Sonoma 14.4.1
• Firefox 124.0.1

[sergei-dyshel]

Getting this on Sonoma with Firefox too.