Chrome performance hit caused by Rectangle's accessibility permissions

[paulirish]

First, thanks for Rectangle! It really does the job.

I've been investigating a performance problem in Chrome and think I can finally point the finger. Unfortunately it points to rectangle. :) I work on the Chrome team, though I'm primarily a web performance guy, and I have limited experience with Chrome's native windowing and accessibility systems.

I've been seeing this event in my traces recently (RenderAccessibilityImpl::SendPendingAccessibilityEvents):

And with a complex page, this can end up taking 500ms, which basically makes the page twice as slow.

chrome://accessibility/ is an internal debug page.. and I noticed that these first two checkboxes were checked:

I know that when they're checked, we see this event and the performance hit.

I found that even when I uncheck them, a few seconds to minutes later they'd recheck. (It looks now like they recheck after focusing another window and coming back to this one)

I went through System Preferences > Security & Privacy > Accessibility and removed a bunch of stuff including Rectangle. And finally they didn't re-enable on their own. I was able to reduce down to trying just Rectangle, and as soon as I added Rectangle's accessibility permission back, these two checkboxes were flipped back on.

But notably, the "Web accessibility" mode is what will enable the SendPendingAccessibilityEvents perf hit. And, I imagine Rectangle only needs "Native accessibility API support"..

So, perhaps there's an ability to be selective in enabling these modes? Clearly you don't have Chrome-specific handling.. and I'm not clear how the mac os accessibility APIs work, or if they could support this level of granularity. But it does seem reasonable for window mgmt apps to flip on APIs to manage windows but not have their contents report all activity to screenreaders, etc.

macOS version: 12.6.3 (21G419) Rectangle version: Version 0.65 (71)

Edit: Oh this is probably a dupe of #912 ..

[paulirish]

Looks like this may be very related: 1364487 - macOS: Toggling AXEnhancedUserInterface started to cause freezes / lags - https://bugs.chromium.org/p/chromium/issues/detail?id=1364487

[rxhanson]

Thanks for digging into it! #912 and that corresponding chrome bug are what I was going to direct you to.

I suspect that you'll be able to determine things a little more quickly by adjusting Rectangle yourself. If you want to tweak Rectangle related to that issue, here's where AXEnhancedUserInterface is toggled: https://github.com/rxhanson/Rectangle/blob/f7569f6062bddbb7a50ee424ddfa5f2edd125037/Rectangle/AccessibilityElement.swift#L107

Rectangle doesn't do anything weird regarding Accessibility - it is literally just using the Accessibility API to get and set the frames of windows, and has to disable AXEnhancedUserInterface to do so if it is enabled.

If you find that there's something to be done related to that issue or not, let me know.

[paulirish]

Whelp, I built it and tried out a few things. I've now commented out all the enhancedUI lines in AccessibilityElement.swift and AXExtension.swift L11... And even with all that gone, these a11y flags do both switch on soon after the system permission is granted. (I'm guessing it happens when the foreground window changes?)

and has to disable AXEnhancedUserInterface to do so if it is enabled.

Also, rectangle still works fine even with those changes. 🤔

[rxhanson]

Rectangle still works fine as long as you don't have other apps that are enabling AXEnhancedUserInterface. Since this is hidden to users, another app can enable it without the user knowing it and Rectangle would appear to just break if it doesn't disable it itself. AXEnhancedUserInterface will animate the resizing and moving of windows via the Accessibility API, which breaks timing that the app relies on to correctly size/position windows, and there's no way around it other than disabling it. There are enough apps out there that will enable AXEnhancedUserInterface, that Rectangle has to account for it. As mentioned by Andreas Hegenberg (of BTT and BetterSnapTool) in that Chrome bug, the way that all of the window manager apps get around this is to toggle off, perform the move/resize, then toggle it back on if it was on beforehand. Unfortunately, this is a scenario that is best handled by Chrome (or Apple), as there's no way to truly fix it as a 3rd party Mac app, other than this workaround. It might be worth pushing back on the fix that went in Chrome side, since apparently that didn't really solve the issue?

[paulirish]

Gotcha. Okay thanks for the verbose explanation. Appreciate it.

Yeah those chrome fixes were... not what I expected. :) I'll poke there a bit more. Thanks

[rxhanson]

Cleaning out old issues... I think this was fixed on the Chrome side so I'm closing this one.