Issue with move parameter and macOS Catalina

[skipcress]

The move parameter does not function properly on my MacBook Pro running Catalina Version 10.15.7. If you use the move parameter by itself, the cursor either fails to move, or it is immediately restored to its original position once any real mouse input is received, I'm not sure which (the cursor disappears until mouse input is received, but when mouse input is received it is clear the mouse hasn't moved. I further verified this by issuing the command: cliclick p && cliclick m:0,0 && cliclick p, and confirming that the cursor location hadn't changed). However, if you use the move parameter and the position parameter as part of the same command, then the mouse cursor moves properly.

In other words, this doesn't work: cliclick m:0,0

...and this doesn't work: cliclick m:0,0 && cliclick p

...but this does work: cliclick m:0,0 p

Here are all the details on the MacBook:

MacBook Pro (Retina, Mid 2012) Processor: 2.3 GHz Quad-Core Intel Core i7 Memory: 8GB 1600 MHz DDR3 Graphics: Intel HD Graphics 4000 1536 MB

Given it's an obsolete machine - and there's a workaround - I'm not too concerned about it, but thought I'd report it anyway in case it's a quick fix, and to document the workaround for the benefit of others.

[alin89c]

Hi! First of all, I have the same Macbook Pro and I run MacOS Ventura 13.5 Beta on it using OpenCore. Go here and download "OpenCore-Patcher-GUI.app.zip". Use the app to download macos 13.5 Betta and create the install media. You'll need a thumbdrive of at least 16GB storage.

Secondly, the solution to what you're asking can be found here.

[BlueM]

As I haven’t been able to reproduce this behavior (neither #168 on a different Mac running macOS 12), I don’t see how I could provide a fix.

[wfaulk]

FWIW, I'm also having this problem on 13.6 on a MacBook Pro "16-inch, 2019" and can confirm that adding the p is an effective workaround.

Actually, adding w:1 is also effective. So is t:1. So is p:1.

Also, rc:. doesn't work without the workaround. And c:. seems to just do a mouse-down without a mouse-up unless the workaround is appended.

Seems like maybe it's a timing issue? Is it possible that it's exiting before it completes the commands?

[wfaulk]

This naive patch seems to fix the move problem:

diff --git a/ActionExecutor.m b/ActionExecutor.m
index d705c81..62a0640 100644
--- a/ActionExecutor.m
+++ b/ActionExecutor.m
@@ -88,6 +88,8 @@ + (void)executeActions:(NSArray *)actions

         if (!options.isLastAction) {
             nanosleep(&waitingtime, NULL);
+        } else {
+            usleep(1000);
         }
     }
 }

but it doesn't seem to help the rc or c problems.

[wfaulk]

And this naive patch seems to fix the click and right-click problems:

diff --git a/Actions/ClickAction.m b/Actions/ClickAction.m
index 00fad2d..cba5559 100644
--- a/Actions/ClickAction.m
+++ b/Actions/ClickAction.m
@@ -57,7 +57,7 @@ - (void)performActionAtPoint:(CGPoint) p {
     CGEventPost(kCGHIDEventTap, leftDown);
     CFRelease(leftDown);

-    usleep(15000); // Improve reliability
+    usleep(25000); // Improve reliability

     // Left button up
     CGEventRef leftUp = CGEventCreateMouseEvent(NULL, kCGEventLeftMouseUp, p, kCGMouseButtonLeft);
diff --git a/Actions/RightClickAction.m b/Actions/RightClickAction.m
index 6602e8d..03518c2 100644
--- a/Actions/RightClickAction.m
+++ b/Actions/RightClickAction.m
@@ -57,7 +57,7 @@ - (void)performActionAtPoint:(CGPoint) p {
     CGEventPost(kCGHIDEventTap, rightDown);
     CFRelease(rightDown);

-    usleep(15000); // Improve reliability
+    usleep(25000); // Improve reliability

     // Right button up
     CGEventRef rightUp = CGEventCreateMouseEvent(NULL, kCGEventRightMouseUp, p, kCGMouseButtonRight);

Weirdly, it fixes the rc problem without needing the previous patch, but it requires the previous patch to also fix the c problem.