Why doesn't the Simulate Scroll Wheel action work reliably?

Questions & Suggestions
1

Why doesn't the Simulate Scroll Wheel action work reliably? It's a simple action, but it just doesn't seem to work reliably. Sometimes it will scroll to the appropriate location. Other times, it won't. It seems to maybe be correlated with how long it's been since a restart of my Mac, but I can't prove that.

Anyway, am I missing something here, or is this a known bug? I can't seem to find any threads at the moment, where others have expressed similar issues, but I swear I've seen other users express similar unreliability.

IF this is a known issue, is there an alternative I should try?

2

I've never seen a problem. Perhaps if you upload a simple macro that doesn't scroll with some app that we have in common, say Safari, that might help.

3

It's not something I have ever heard of.

The manual scroll wheel behaviour is not especially reliable or repeatable in my experience, so I don't know if that might be playing in to the issue.

Keyboard Maestro can only simulate the events, what the target application does with them is frequently beyond control.

The behaviour of scroll wheel also is exceptionally sensitive to the mouse location and the content of the window under the mouse.

4

When you say that the "manual scroll wheel behavior is not especially reliable or repeatable", can you elaborate on what you mean by that?

Also, when you say that the "behavior of scroll wheel also is exceptionally sensitive to the mouse location and the content of the window under the mouse", can you elaborate on what you mean by that?

In both cases above, I wasn't aware of either of these situations being a "thing".

5

The macro I'm using is specific to an app (Luna) that you'll almost certainly not have.

The bigger smoking gun for me here is that, when using the app and macro immediately after a restart of my Mac, the simulate scroll wheel action in KM works as it should. But, after some period of time, the simulate scroll wheel action starts to misbehave. The interesting thing is that, once it starts misbehaving, it misbehaves in the same way every time. When misbehaving, the macro seems to "reliably" scroll further than it should, by about ~12 pixels. This "over scroll" of ~12 pixels results in the mouse not landing on the button it is supposed to land on, prior to clicking the mouse. It's a head scratcher.

6

That's important information that helps clarify the problem. So the problem is with that app's handling of the scroll wheel signal --> but only after some time. Does that app also have issues when you actually use the real scroll wheel on your mouse (after some time)? Or does the physical mouse always work perfectly?

There's no Luna app on the MacOS App Store, so can you be more specific about which app you are talking about so I can look into it? Are you talking about the Luna app for iPadOS? For the purpose of this response, I will assume Luna is a macOS app.

During that "period of time" both the KM Engine and the Luna app itself both can potentially be affected by time. For all we know, it could be the Luna app that's behaving differently as time goes on, not the KM Engine necessarily. Based on the information we have so far, it could be the Luna app that behaves differently as time goes on. It sounds like you expect the issue to be with the KM Engine, but we have no specific proof of that idea yet.

For example, the Luna app could have a timing issue that's occurring less often when the app starts compared to when it's running for a long time. For example, if you've loaded a large file into the Luna app it may respond to certain inputs with some lag. Have you checked your macOS Activity Monitor to see how much RAM and CPU the Luna app (and the KM Engine) are using as time goes on?

It also might be a completely different app that's using more resources over time. Perhaps you are using a CPU-heavy app like "Voice Control" when it's failing. Are you sure that you haven't started or used any other apps between the time that it works correctly and the time that it doesn't work?

At this time my opinion is that something is bogging down the system when it isn't working for you, so the next step would be to figure out what extra software or extra activity is occurring when it's not working for you.

He's referring to the actual scroll wheel on a physical mouse. Clearly, if a physical mouse is unreliable with macOS, the KM Engine can't fix that problem, because the KM Engine is simply emulating the physical mouse. So it's important to check if your physical mouse always works perfectly with the Luna app.

7

Luna isn't available on the Mac App Store. It's DAW software from Universal Audio, and would have to be downloaded from their site. However, it's a large piece of software, and I wouldn't bother downloading it.

As for the mouse, this is on a MacBook Air, so it's just a track pad. No mouse. That said, there is no way to test to see if it works, as the whole point is the automation in KM. Using the trackpad scrolls within Luna, obviously, but it's not about whether or not it scrolls. It's about it scrolling a specific number of pixels in a repeatable fashion, and that is the issue when using the Simulate Scroll Wheel action in KM.

Of note, I just tested to see what happens when I quit the KM engine, and then restart the KM engine, and things work as they should again. So I think it IS still a KM issue. Nothing else is changing, other than quitting and then restarting the KM engine.

When things are working as they should, it scrolls the proper number of pixels, and places the cursor in the correct spot on top of the button I want it to push. After things start misbehaving, it places the cursor 12 pixels below where it should be, which means that it is not on top of the button. This happens in a repeatable fashion. It continues to misplace the button 12 pixels below where it should be. Then, if I reset the KM engine, it goes back to working correctly. So this doesn't seem very random. it seems to be something to do with KM itself.

In any case, my buttons are large enough that I've now managed to change my pixel numbers designated in the Simulate Scroll Wheel action so that, whether or not KM is misbehaving, the cursor still falls somewhere on the button, which is the important part. I'd still like to understand why I'm having this issue, but at least my macro ultimately works now. Thankfully, the buttons are big enough, that 12 pixels of variability in the scroll movement is smaller than the total pixel size of the button.

8

Yes, some of the evidence is now pointing that way. Please pardon me for not simply trusting you, but trust isn't always a good value when debugging things.

Of course, it could still be macOS's GUI and/or timing issues. Peter said something similar when he said, "the manual scroll wheel behaviour is not especially reliable or repeatable." And when he says that, he's talking about the OS/GUI and the hardware, not the KM Engine.

9

No worries. When debugging things, there is always the obligatory "did you restart it?" question... :wink:

Yeah, that's why I wanted Peter to elaborate on what he was talking about. I'd like to know more about what he was referring to on the scroll not being reliable.

As for the scroll simulation, it seems like this is something that ought to be simple and repeatable, but there seems to be more to it than this. Maybe it's how KM interacts with Mac OS? I don't really know.

1 Like
10

I mean that if you scroll up and down in the middle of a page a bunch you wont necessarily get back to where you started.

If there are any scrollable areas within the window, then the behaviour of the scroll wheel will be change as the are moves under the mouse.

I'm not aware of any guarantee in macOS that a scroll wheel movement leads to pixel perfect movement of the window.

The Simulate Scroll Wheel action is relatively simple and adds scroll events to the system queue, with the scroll quantity and direction determined by the value from the action, and broken in to steps of 10 or less.

There is very little opportunity for it not to simulate the events:

  • The action could not be being executed because some previous action fails and aborts the macro.
  • The calculation fails to produce the desired result.
  • The macro is aborted before or during the action execution.
  • The system decides to drop the events for some reason.

Other than that, it is virtually impossible for the events not to be simulated in sequence.

What happens with the events after that is entirely up to the system and the target application and beyond Keyboard Maestro’s control - Keyboard Maestro does not scroll the underlying window/areas, it simply posts the scroll wheel movements.

I would add a Log action before and after the action to verify the scroll action is being executed, and that the desired value is being calculated (if it is not a simple number).

But if it is, then the events will be being simulated.

2 Likes