Repositionning and resizing windows is super slow for Chrome

[bligneri]

• [x] This is a new bug that hasn't been documented in a closed issue or in the Readme.

macOS version: 12.5.1 Rectangle version: v0.59 (65)

It works well for Safari and other apps and this behaviour is only present for chrome.

Chrome version is the most recent: Version 105.0.5195.102 (Official Build) (arm64)

Logs if applicable (In Rectangle menu, hold option, "View Logging..."):

2022-09-08T15:43:19-04:00: AXEnhancedUserInterface was enabled, will disable before resizing 2022-09-08T15:43:26-04:00: AX sizing proposed: (1504.0, 1667.0), result: (1504.0, 1667.0) 2022-09-08T15:43:26-04:00: AX position proposed: (0.0, 25.0), result: (0.0, 25.0) 2022-09-08T15:43:26-04:00: AX sizing proposed: (1504.0, 1667.0), result: (1504.0, 1667.0) 2022-09-08T15:43:26-04:00: leftHalf | display: (0.0, 0.0, 3008.0, 1667.0), calculatedRect: (0.0, 25.0, 1504.0, 1667.0), resultRect: (0.0, 25.0, 1504.0, 1667.0), srcScreen: LG HDR 4K, destScreen: LG HDR 4K, resultScreen: LG HDR 4K 2022-09-08T15:43:28-04:00: AXEnhancedUserInterface was enabled, will disable before resizing 2022-09-08T15:43:35-04:00: AX sizing proposed: (1504.0, 1667.0), result: (1504.0, 1667.0) 2022-09-08T15:43:35-04:00: AX position proposed: (1504.0, 25.0), result: (1504.0, 25.0) 2022-09-08T15:43:35-04:00: AX sizing proposed: (1504.0, 1667.0), result: (1504.0, 1667.0) 2022-09-08T15:43:35-04:00: rightHalf | display: (0.0, 0.0, 3008.0, 1667.0), calculatedRect: (1504.0, 25.0, 1504.0, 1667.0), resultRect: (1504.0, 25.0, 1504.0, 1667.0), srcScreen: LG HDR 4K, destScreen: LG HDR 4K, resultScreen: LG HDR 4K 2022-09-08T15:43:46-04:00: AX sizing proposed: (1504.0, 1667.0), result: (1504.0, 1667.0) 2022-09-08T15:43:47-04:00: AX position proposed: (1504.0, 25.0), result: (1504.0, 25.0) 2022-09-08T15:43:47-04:00: AX sizing proposed: (1504.0, 1667.0), result: (1504.0, 1667.0) 2022-09-08T15:43:47-04:00: rightHalf | display: (0.0, 0.0, 3008.0, 1667.0), calculatedRect: (1504.0, 25.0, 1504.0, 1667.0), resultRect: (1504.0, 25.0, 1504.0, 1667.0), srcScreen: LG HDR 4K, destScreen: LG HDR 4K, resultScreen: LG HDR 4K 2022-09-08T15:43:48-04:00: AX sizing proposed: (1504.0, 1667.0), result: (1504.0, 1667.0) 2022-09-08T15:43:48-04:00: AX position proposed: (0.0, 25.0), result: (0.0, 25.0) 2022-09-08T15:43:48-04:00: AX sizing proposed: (1504.0, 1667.0), result: (1504.0, 1667.0) 2022-09-08T15:43:48-04:00: leftHalf | display: (0.0, 0.0, 3008.0, 1667.0), calculatedRect: (0.0, 25.0, 1504.0, 1667.0), resultRect: (0.0, 25.0, 1504.0, 1667.0), srcScreen: LG HDR 4K, destScreen: LG HDR 4K, resultScreen: LG HDR 4K 2022-09-08T15:43:55-04:00: AX sizing proposed: (1504.0, 1667.0), result: (1504.0, 1667.0) 2022-09-08T15:43:55-04:00: AX position proposed: (1504.0, 25.0), result: (1504.0, 25.0) 2022-09-08T15:43:55-04:00: AX sizing proposed: (1504.0, 1667.0), result: (1504.0, 1667.0) 2022-09-08T15:43:55-04:00: rightHalf | display: (0.0, 0.0, 3008.0, 1667.0), calculatedRect: (1504.0, 25.0, 1504.0, 1667.0), resultRect: (1504.0, 25.0, 1504.0, 1667.0), srcScreen: LG HDR 4K, destScreen: LG HDR 4K, resultScreen: LG HDR 4K

[rxhanson]

Thanks for reporting. I went ahead and checked in a change for this, so it'll be in the next release.

What's going on here: "AXEnhancedUserInterface was enabled, will disable before resizing" refers to a weird hidden setting of macOS that can be toggled per application. If it is enabled, then window move/resize will be animated. This breaks Rectangle's move/resize behavior because Rectangle issues resize/move/resize per command, and the subsequent calls will terminate the prior one early when animation takes place, resulting in incorrect sizes/locations. The act of disabling this setting also creates a lag in some applications. Prior to the change I just checked in, Rectangle will disable then re-enable this setting for every window command. Now, it will not re-enable the setting, so all subsequent commands should be immediate after the first one (as long as it's not re-enabled by something else). All that said, you might be wondering how that was enabled for you in the first place. The most common app that enables this is the built-in on-screen keyboard in macOS, but there are a few other obscure apps that do it.

[bligneri]

Thanks for your super fast answer.

I am not sure how this setting was enabled. Based on what you shared above, I would say that it could be because of a recently installed screen capture/recording app?

I have two candidates: Xnapper and CleanShot that I am testing.

I could remove these apps and test this hypothesis if this is helpful?

[rxhanson]

It probably wouldn't help too much, unless the change I just put it doesn't work for you - so we can wait until the next release to dig deeper if needed. It would be kind of a pain to figure out since you'd have to log out/log back in without each app running to see what happens since it only has to get enabled once to take effect for the session.

[v0y4g3r]

Same problem here, resize/move commands hang for seconds on Chrome. "AXEnhancedUserInterface was enabled, will disable before resizing" also appears in logs. Any workaround?

[rxhanson]

@v0y4g3r, You can install the auto-generated build, but it's not signed so you'll have to bypass gatekeeper to run it: https://github.com/rxhanson/Rectangle/actions/runs/3018034941

(or you can wait for the official release - not sure when that will be though, or figure out what app is triggering this functionality with Chrome and stop using that app, or stop using Chrome)

[v0y4g3r]

@v0y4g3r, You can install the auto-generated build, but it's not signed so you'll have to bypass gatekeeper to run it: https://github.com/rxhanson/Rectangle/actions/runs/3018034941

(or you can wait for the official release - not sure when that will be though, or figure out what app is triggering this functionality with Chrome and stop using that app, or stop using Chrome)

Thanks a lot, this build works.

[juzijun233]

@v0y4g3r, You can install the auto-generated build, but it's not signed so you'll have to bypass gatekeeper to run it: https://github.com/rxhanson/Rectangle/actions/runs/3018034941

(or you can wait for the official release - not sure when that will be though, or figure out what app is triggering this functionality with Chrome and stop using that app, or stop using Chrome)

Tried using this version, but the problem persists. When operating chrome browser and edge, its window freezes

[rxhanson]

@juzijun233 It's likely that you are experiencing a different issue.

Do you see this message in your logs? (In Rectangle menu, hold option, "View Logging...")

AXEnhancedUserInterface was enabled, will disable before resizing

If you continue to see that with the unsigned build, then that means an app you are using is continuing to reset AXEnhancedUserInterface, and you'll have to figure out which one it is and either stop using it or get that app developer to fix it so it doesn't do that.

If you don't see AXEnhancedUserInterface in the logs, then we're still looking at something that isn't an issue Rectangle side (sorry!). It could be an issue with Chromium and/or something specific to your Mac.

[v0y4g3r]

AXEnhancedUserInterface

How can I figure out which app is altering AXEnhancedUserInterface config?

[rxhanson]

As far as I know, the only way would be to one-by-one try it out and keep track of the logging in Rectangle.

The only apps I know for sure that have caused this in the past are:

1. The on-screen keyboard built into macOS
2. Dragon (dictation)
3. Punto (a Russian language switching app)

https://github.com/rxhanson/Rectangle/issues/165 is an aggregate issue with all of the old tracking for this problem, from before someone created a pull request that disabled AXEnhancedUserInterface. Back then I had filed an issue with Apple about it, but it never got any attention.

[ibash]

@rxhanson I tested the build, thanks!

Just FYI with the new build the issue still persists the first time rectangle changes the position of a chrome window. After that the issue is no longer there until I quit and restart rectangle app.

Works well enough for me, but thought I'd let you know.

[v0y4g3r]

Did a binary search thru all running apps, turned out to be a input source auto switch helper. If I enable the enhanced mode, it will continously set AXEnhancedUserInterface to true.

[rxhanson]

@ibash, thanks for letting me know. This is to be expected, as that's when Rectangle will disable it the first time (which creates the lag). Maybe a better solution is just to check when an app becomes frontmost, and prompt the user once about disabling it. There are scenarios, as displayed by Input Source Pro, where EnhancedUI might be desirable, and ultimately it's up to the user to know that it makes Rectangle commands lag on certain apps and make a choice accordingly. I'll have to think about a better way, since this is annoying as an end user regardless.

[rxhanson]

(and thanks @v0y4g3r for the follow up on that input source app!)

[scranton]

Build #281 solved the slow chrome problem for me after the second move command, as expected. Thanks for the fast response!

[ibash]

I'm periodically getting slow window resizing in chrome. I haven't been able to trigger it reliably, but it does happen. Will let you know if I find reliable reproduction steps.

[fifafu]

Unfortunately I'm hitting the same issue in my apps (BetterTouchTool/BetterSnapTool). I think there must have been a recent change in either Chromium or macOS because disabling & reenabling AXEnhancedUserInterface has worked well for like 10 years now :-). AFAIK the issue only affects Chromium based applications and I have been getting reports about it for about 1-2 weeks.

The problem is, some popular apps like Grammarly will constantly be reactivating the AXEnhancedUserInterface because that's the only way for them to access browser elements via the Accessibility API. So just disabling without reenabling it, will not fix this issue. Maybe 1Password is also affected, because I think they are also enabling AXEnhancedUserInterface sometimes since 1Password 8 - this gives me some hope the issue will be addressed.

If you have any more information, I have created an issue at Chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=1364487

Related thread for BetterTouchTool: https://community.folivora.ai/t/window-snapping-for-google-chrome-freezes/28462/

[EvanGoss]

The newer build (https://github.com/rxhanson/Rectangle/actions/runs/3018034941) improves the situation for me.

I've identified two screenshot utilities on my system that appear to turn on AXEnhancedUserInterface:

https://shottr.cc/ https://monosnap.com/

I've had them both installed for over a month and just started experiencing an issue in the last few days and the only app that seems to be affected on my system is Chrome (currently running 105.0.5195.125).

I don't know if it is relevant, but I haven't been able to replicate the issue in Chrome Canary (107.0.5304.0).

[wanderr]

This build fixes it for me as well (after one final slow reposition)

[ibash]

Hi folks, just FYI if you want this bug fixed sooner then go to the chromium issue and star it: https://bugs.chromium.org/p/chromium/issues/detail?id=1364487

The more stars the more likely it gets fixed sooner rather than later.

[wanderr]

On further usage, this build is not much help, I guess something keeps turning on AXEnhancedUserInterface so I keep hitting the massive lag in repositioning Chrome. I starred the chromium bug, but any other workarounds would be greatly appreciated...

[fifafu]

I believe most users who encounter the problem have the Grammarly app running. So until this is fixed in Chrome, the only viable workaround would be to disable Grammarly for Chrome.

[thewoolleyman]

Running latest build fixes it for me (I also uninstalled Grammarly first, but that did not help).

Also upvoted the chromium bug 🤞

[strokirk]

I've also been able to solve the problem by exiting shottr.cc, although optimally I'd still like to use it, of course.

[kareemaljabr]

I'm having the issue while on the latest version 0.59. Was the issue fixed for the pro version only?

[rxhanson]

@kareemaljabr Any bug fixes go into both apps, but there can be delays in terms of when I cut a release for either one. I wouldn't fix something in one and leave it broken in the other.

There is not a "complete fix" put into either one. This is an issue that is best fixed Chrome side, and a fix Rectangle side would be a workaround. You can install the auto-generated build mentioned in the thread that contains a workaround, and doesn't come with a guarantee that it will fix it for everyone. It's not signed so you'll have to bypass gatekeeper to run it: https://github.com/rxhanson/Rectangle/actions/runs/3018034941

If you are using pro, you can enable this workaround as mentioned here: https://github.com/rxhanson/RectanglePro-Community/issues/129

[ako111]

Clearing browsing data in Chrome fixes the problem as well 🙏

[juzijun233]

It seems that this problem no longer exists in edge's 106.0.1370.34 (official version) (arm64)

[fifafu]

@juzijun233 the issue still exists in Edge, it has not yet been addressed by Chromium. It's not always immediately happening, you need to open some large sites / multiple tabs.

However first workarounds are being discussed in the Chromium issue, so let's hope it will be fixed soon :-)

[myorg]

I installed the suggested build (https://github.com/rxhanson/Rectangle/actions/runs/301803494) and it didn't seem to have an impact and performance was still negatively impacted, sometimes for up to a minute when resizing Chrome windows.

Per someone else's suggestion above, I turned off Grammarly and all of the sudden the non-responsiveness after resizing disappeared!

[rhuss]

I suffer from the very issue of using the combination Rectangle, Grammarly, and Brave (which has Chromium inside). Even when I disable Grammarly, Brave gets very unresponsive all of a sudden (I'm using the latest released version of Rectangle, not the nightly build)

My "solution" so far is to switch to Firefox as a browser, but that is of course only a workaround.

[JayHenrysHangry]

Yeah this has been terrible waiting for Chrome to freeze and resize. When will this fix be going out?

[rxhanson]

@JayHenrysHangry This is an issue Chrome side. https://bugs.chromium.org/p/chromium/issues/detail?id=1364487

Adjusting this behavior in Rectangle would be merely a workaround for something best fixed Chrome side.

[rxhanson]

Version 0.60 has been released, and includes the workaround, but it can only be enabled via terminal command.

defaults write com.knollsoft.Rectangle enhancedUI -int 2

This will disable AXEnhancedUI when windows get resized, and it will not re-enable it after. (This was the change that was in the referenced auto-generated build).

Alternatively, you can try this:

defaults write com.knollsoft.Rectangle enhancedUI -int 3

This will disable AXEnhancedUI when frontmost application changes.

Restart the app after executing either of those. Setting it to 1 or 0 will undo those changes.

As mentioned, these are workarounds, and they don't "play nicely" with other apps that could rely on AXEnhancedUI being enabled. It's for this reason that I have only allowed them to be toggled via terminal command, and the underlying issue is still best resolved Chrome side.

[andsimakov]

I tried to apply defaults write com.knollsoft.Rectangle enhancedUI -int 3 on my system and it even helped me with Chrome. But then I started to notice constant freezes in Chrome on any action: switch to Chrome, switch tabs in Chrome, switch windows in Chrome. All the time I got the spinning candy cursor. I closed the Rectangle app and didn't have any issues so far. I'm on Intel MBP. Chrome is 107.0.5304.110, macOS 12.6.1. I should say I don't have such kind of issues on my Apple Silicon-based Mac mini.

[mohamed-haidara-cko]

I tried to apply defaults write com.knollsoft.Rectangle enhancedUI -int 3 on my system and it even helped me with Chrome. But then I started to notice constant freezes in Chrome on any action: switch to Chrome, switch tabs in Chrome, switch windows in Chrome. All the time I got the spinning candy cursor. I closed the Rectangle app and didn't have any issues so far. I'm on Intel MBP. Chrome is 107.0.5304.110, macOS 12.6.1. I should say I don't have such kind of issues on my Apple Silicon-based Mac mini.

Had the same issue and reverted to defaults write com.knollsoft.Rectangle enhancedUI -int 1 to make Chrome work seamlessly again. Intel Mac Big sur and Chrome 107.0.5304.110 (Official Build) (x86_64)

[davidawad]

The fix by @mohamed-haidara-cko of setting enhancedUI to 1 worked for me, setting to 3 did not.

[rxhanson]

Setting enhancedUI to 1 is the equivalent of making no changes to how Rectangle works. If this works for you, then you're looking at some intermittent behavior from Chrome.

Note that you do have to restart Rectangle for a terminal command modification to take effect.

[alexagv]

I have the same issue and tried the enhancedUI -int 2 and 3.

It made Chrome hang on first try (the usual 3s delay), then it was fast afterwards. However when using other programs (so chrome is not the active window), and going back to Chrome it was slow on first try again, then fast again until the next time the window was not active and activated again.

My setup: M1 MacBook Pro and Chrome and I use Grammarly running rectangle 0.63

[alicancakil]

I am experiencing same issue. I am running v0.63 with latest version of chrome (Version 107.0.5304.110 (Official Build) (x86_64))

defaults write com.knollsoft.Rectangle enhancedUI -int 2 did not help at all.

[zzJinux]

It seems that related patch ships on Chromium 109: https://github.com/chromium/chromium/commit/049899191b19a5508057e10d5e2a4eeb414ad014 (tell me if I'm wrong)

... and Chrome 109 has a long way to land on the stable channel 😢: https://chromestatus.com/roadmap

[rxhanson]

@zzJinux Looks like you're right! Thanks @fifafu for creating the Chrome ticket and posting it here.

[gmpetrov]

It seems that related patch ships on Chromium 109: chromium/chromium@0498991 (tell me if I'm wrong)

... and Chrome 109 has a long way to land on the stable channel 😢: https://chromestatus.com/roadmap

I switched to chrome canary (v110) https://www.google.com/chrome/canary/ and the issue looks fixed 👍

[xspade]

I tried both enhancedUI -int 2 and enhancedUI -int 3, and it seemed to make Chrome usable; however, it was still noticeably slow, especially after moving to another display. Resizing seemed to have less of an effect, but it's hard to tell because it's inconsistent.

Everything seems to be working perfectly on Canary, though! 🎉

[fikrikarim]

As noted on the other issue #165, I just updated my chrome to the latest stable build and this solves the issue!

Version 108.0.5359.94 (Official Build) (arm64)

No need to wait for Chrome 109 or Chrome 110. Just go to chrome://settings/help and it'll update your chrome to Chrome 108.

[jdugan1024]

FYI -- I just updated Brave, and the fix seems to have percolated down into Brave as well.

[paulirish]

I just filed a dupe in #1065, but I'll add some details here that should help folks more obviously identify the problem...

chrome://accessibility

The chrome://accessibility page covers some chrome accessibility internals, but it looks like the first two checkboxes ~correlate to this AXEnhancedUserInterface property:

chrome traces

Then, you can capture a trace to see the lag, and attribute all the time spent handling accessibility work. There's a few different ways, but the easiest:

1. open chrome://tracing in Chrome/Chromium
2. hit Record
3. Select 'Manually select settings', then under 'Record Categories' deselect all the below checkboxes with the 'None' button. Then check the 'accessibility' category checkbox. (screenshot below)
4. Hit record in the bottom right
5. Do the action that is slow/laggy, and stop the recording. (Ideally the recording is <10 seconds)
6. You can navigate this UI with WASD and scrolling. You'll find a big RenderAccessibilityImpl::SendPendingAccessibilityEvents event within a 'Renderer' pid in these problem situations. (screenshot below)

[juliangarnier]

@paulirish thanks for posting this! That helped me find a temporary fix to the issue by launching Chrome with the --disable-renderer-accessibility flag. This will disable all the "Accessibility modes" features and prevent them from being activated by Rectangle.

Before disabling the "Accessibility modes":

After:

So for anyone reading this and looking for a quick workaround: quit Chrome and re-open it via the terminal by adding this flag: /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --disable-renderer-accessibility

[LucaMarconato]

I encountered the bug today, I tried quitting Grammarly (desktop app) and the problem disappeared. Removing the Chrome extension was not enough. I reported this to Grammarly, hopefully there will be a fix to this weird bug.

[rxhanson]

Closing this one out, since there's nothing further to be done within Rectangle for it.