Window Snapping & Moving, Horrible delay problem

I have window move/resize configured to activate with SHIFT and OPTION/CMD modifier keys.

Before the Sonoma update, this worked well with zero delay. However, currently, it is delayed for 5-10 seconds or lots of times doesn't work at all.

How can I resolve this issue? I use this feature frequently. Is anyone else experiencing this problem?

That sounds like something (possibly another app) might be interfering, in general there is still close to zero delay on macOS Sonoma.
You have configured this here, correct?

Is there any process in activity monitor that is using a LOT of cpu? (> 100%)

I checked and tried different configurations for moving and resizing, but I keep getting the same result.

There is nothing abnormal in Activity Monitor.

You might be right that another application is causing this issue.

  • I am using three Macs with Universal Control. When I tested the third Mac with its own keyboard and mouse, it worked well with no delays.
  • Unfortunately, the host computer and the second Mac always have this problem, even when using their own keyboards and mice.

I don't understand. I will try using "safe mode".

  • If I get different results, I will share

  • I can say that if I use this feature almost continuously, it responds faster, but when I try it without using it for 10-20 seconds, I experience a lot of delay.

are you using custom defined snap areas in BTT?

No, I did not customize this area and the same problem persists when I create a new and empty "preset".

Ok, then unfortunately I have no idea what could be causing this ;-(
I'd try quitting app by app and see whether anything changes.

Problematic apps would probably be listed in the accessibility section in System Settings => Security & Privacy

Maybe I found the problem, it works fine now.

I'm using "Synergy Project" on host Mac. When I remove its access from Accessibility and then restart BTT, everything works well.

I don't know how I can handle this because I have one Windows machine in my setup, and I need to use Synergy.

Anyway, we found something. I'll try a few more things and if I find something new, I'll share it here.

interesting. Synergy needs to integrate in similar ways as BTT does, maybe that's causing issues. However I haven't heard of specific problems with synergy in the past :-/ Maybe it's a specific version of synergy?

I just checked and I'm using the latest version.

There is still a delay from time to time, maybe it is not related to Synergy or there are other factors. However, it still works better when Synergy is turned off.

I found another interesting thing: if I try it from the top of the windows rather than from the bottom, the result is always like this. I get the same result in Finder and Safari

Mhh that looks like there is an invisible overlay that blocks BTT from accessing the window below

Can you try going to the advanced trigger conditions configuration in some BTT trigger:


Click the "Hovered Element Viewer" button

And then check what it shows when you hover the bottom part of the screen?

OK, I found a few things, I'm adding screenshots. I use a lot of "Floating Webviews". Once I open and hide them, "move/resize" does not work in these areas.

This explains why it works fine when I reboot.

I'm also attaching a sample "floating webview" screenshot. Is there a setting I can make to prevent this?

I can reproduce this!

Should be fixed in 4.558 (uploading now), thanks a lot for finding & reporting

It was my pleasure, I'm looking forward to the update.

should already be available (unless your are using setapp, then it will take a few days)

I updated it, it works great, the problem is completely solved

1 Like

There's just one more thing,

I created a new "float webview". If I select the "stick to desktop" option, move/resize does not work in that area, even though the float webview remains behind.

good point, I’ll fix that!

1 Like