Delay in AppleScript workflows on Monterey with arm64

[bmamlin]

I'm enjoying Alfred on my spiffy new arm64-based MacBook Pro running Monterey (macOS 12.0.1), but started having situations where Alfred workflows weren't responding. Then I noticed they were responding, just taking 10-20 seconds before they would run. With a little more investigation, I discovered these were workflows that use AppleScript (of which I have many).

 

Everything behaves normally for a while, then AppleScript-containing workflows start suffering from this unbearable delay (I haven't figured out what triggers the problem to start). Restarting my laptop fixes the problem for a while, but eventually I end up with delayed workflows again. I haven't rebooted a laptop this often since I was using Windows.  

 

I made a little dummy workflow that just runs this AppleScript and then displays a notification, so I can easily test for the delay:

tell application "System Events"
	do shell script "ls"
end tell

 

Am I alone in having this problem? I'm assuming it's more of a problem with Monterey than Alfred, but I'd love to know if there's a workaround (other than rebooting).

[deanishe]

7 minutes ago, bmamlin said:

Am I alone in having this problem?

 

I've not seen it mentioned before. The obvious cause for a long delay in an AppleScript is an application that isn't responding.

 

Which applications do the problematic scripts call? Are there any common ones?

[bmamlin]

18 hours ago, deanishe said:

Which applications do the problematic scripts call? Are there any common ones?

It doesn’t matter. Anything sent to System Events seems to be affected. For example, in my example above I’m just executing a directory listing (ls command), which should take a fraction of a second, and even that is delayed. 

[deanishe]

5 hours ago, bmamlin said:

Anything sent to System Events seems to be affected

 

System Events is an application. Are you saying that you only have a problem with System Events?

 

5 hours ago, bmamlin said:

in my example above I’m just executing a directory listing (ls command), which should take a fraction of a second, and even that is delayed.

 

I can see. It wasn't clear from your description above that the script actually suffered from the problem, only that you'd written it to test it.

[vitor]

In addition to what Dean asked, it isn’t clear if you tried running your code in Script Editor.

 

As another data point, I’m on ARM and Monterey and your code is fast for me, both in Script Editor and Alfred.

[bmamlin]

On 12/4/2021 at 4:53 PM, deanishe said:

It wasn't clear from your description above

 

30 minutes ago, vitor said:

it isn’t clear if you tried running your code in Script Editor

 

Yeah, sorry about that. I noticed the problem when I ran my workflow to unmute/mute Zoom calls (uses AppleScript to manipulate Zoom's menu) and it was running ~15-20 seconds after I triggered it. The first thing I did was run the script through the script editor and saw the same behavior (taking 15-20 seconds to execute), which showed it was an AppleScript/Monterey issue and not an Alfred-specific issue. The next thing I did was to create a simple workflow (i.e., run the simplest shell command via AppleScript before posting a notification), so I could more easily test for the condition before joining a Zoom call. When the delay is happening, even that simple workflow is noticeably delayed. Rebooting definitely fixes the problem for a while. Since my last reboot, everything is working as expected without delay.

 

I haven't figured out what makes the delay start happening, but it seems to only be a matter of time before it starts happening again. While it might be an issue with Monterey on arm64, I'm hoping it's a temporary issue with a background service having Monterey compatibility issues (e.g., BetterTouchTool, BetterSnapTool, iStats, etc.), many of which have been getting updates over the past few weeks for Monterey compatibility... and hopefully I won't see it again. If it does re-appear, I'll see if it's only a problem for scripts using System Events (though, that covers most my AppleScript-based workflows).

[deanishe]

2 hours ago, bmamlin said:

though, that covers most my AppleScript-based workflows

 

What are you doing? You don’t need System Events to run do shell script, for example.

 

[bmamlin]

14 minutes ago, deanishe said:

What are you doing? You don’t need System Events to run do shell script, for example.

 

Some examples:

• Muting/unmuting Zoom calls
• Manipulating menubar apps (e.g., getting position of an item to send simulated clicks with cliclick)
• Bring Chrome tab with Gmail to front (switching to window & tab if I've already got in open somewhere; otherwise, creating a new tab). Most of this doesn't use System Events, but it was delayed, but it does ask System Events to tell Chrome to perform "AXRaise" to ensure it's brought to the front. If I get the delay again, this would be a good one to test if this small step is responsible for the delay.
• Controlling TiVo, including keystroke simulations to stage the next TiVo command into Alfred's prompt
• Manipulating position of windows
• Various scripts to load things into the clipboard (a new UUID, public key, etc.)

Looking through my workflows, the above only represents ~25% of what I use, so you're right that most of my workflows don't use AppleScript or, if they do, don't use System Events. While many of the above might be able to be refactored to avoid System Events, they've worked fine for years and – as long as this delay isn't happening – they work just fine. As it stands, it sounds like this isn't a prevalent problem, so hopefully already fixed with recent updates and it won't return. If it does, I'll try to figure out what I'm doing just before it starts and hope to find an offending script or app behind it.

 

In any case, thanks for your help! At this point, at least I know it's not something everyone running AppleScript workflows with Monterey on arm64 is encountering. If it returns, I'll try to do some more debugging.

[deanishe]

1 hour ago, bmamlin said:

As it stands, it sounds like this isn't a prevalent problem, so hopefully already fixed with recent updates and it won't return.

 

I think the most likely explanation is that something else you have installed is interfering. This is the only similar issue I found.

 

Testing the scripts under a different, clean user account will tell you if the problem's in the system or your account.

[bmamlin]

Well, I made it a day without the slowness recurring, but it showed up again today. Unfortunately, there wasn't any obvious inciting event (I hadn't just opened something or run something for the first time).

 

It's definitely an issue with using "System Events". This simple AppleScript:

tell application "System Events"
	do shell script "ls"
end tell

takes several seconds (usually returns instantly). When I loaded one of my more complicated scripts (finding my Gmail chrome tab and switching to it), taking out the call to "System Events" to send "AXRaise" made it run instantly (just not reliably bring the window to focus); whereas, running with the "System Events" call worked but the tab being brought into focus via the "AXRaise" event was delayed at least 5-10 seconds.

 

I tried closing down every app & service and the delay persisted. Logging out and logging back in fixes the problem, so at least I don't have to reboot. I've found some references to people having similar problems (e.g., here and here). Until I can figure out what causes it to happen (other than using my laptop for a day until it "randomly" recurs), I can't reliably recreate the problem and troubleshoot the cause. 😕

 

Thanks to the Alfred community for helping me think through it. It's clearly not an Alfred-specific issue, just manifesting itself through Alfred since I use AppleScript with calls to "System Events" in some of my workflows. Sorry for filling Alfred's forum with non-Alfred issues (at least I'm not alone 🙂). I've already started to move away from calling "System Events" wherever I can in my Alfred workflows, but I'm not sure how to do things that require UI manipulations (like selecting menu items from a menu bar app that doesn't support scripting or getting Chrome's window to grab focus) without the use of "System Events" in AppleScript.

 

 

[vitor]

If you ever find the cause and/or a solution, I’d still encourage you to post in this thread as followup. The thread already exists and is probably indexed by search engines anyway, so it may provide help to someone else in the future, Alfred user or not.