Around 10% of the time, seemingly at random, the Activate Application action does not work. It does run, doesn't timeout, and doesn't fail, but it doesn't do anything.
I have bolstered the macro here with some logging and an Until loop to demonstrate the issue.
Here's a snippet from the logs, showing 3 runs: Success-Failure-Success
2023-12-06 12:23:50 Execute macro “Fix Chrome bug affecting NetNewsWire” from trigger The Hot Key B is pressed
2023-12-06 12:23:50 Log: Attempted NNW Activation
2023-12-06 12:23:50 Log: NNW Activated
2023-12-06 12:23:52 Execute macro “Fix Chrome bug affecting NetNewsWire” from trigger The Hot Key B is pressed
2023-12-06 12:23:52 Log: Attempted NNW Activation
Last message repeated 2 times
2023-12-06 12:23:52 Log: NNW Activated
2023-12-06 12:23:55 Execute macro “Fix Chrome bug affecting NetNewsWire” from trigger The Hot Key B is pressed
2023-12-06 12:23:55 Log: Attempted NNW Activation
2023-12-06 12:23:55 Log: NNW Activated
(Note that "Failure" here is symbolic: because of the Until loop, the action is successful eventually, but "Last message repeated 2 times" indicates that the action wouldn't have worked if it had only run once.)
I tried searching the forum, but couldn't find anything about this specifically.
Am I missing anything glaring? I don't want to bother Peter and cry "bug" without some expert opinions.
I'm not an expert, but I'm a seasoned user. And I think you are expecting something that I wouldn't expect. When I activate an application, I expect that KM tells macOS to activate an application, but then macOS will return immediately and start up the application asynchronously, which means the application may not be "at the front" for quite a period of time after your action to activate it. Maybe several seconds. Or longer. (In fact, some apps never come to the front.)
MacOS does start the app on the first call in your macro, I suspect, and you seem to be thinking (when you said, "the action does not work. It doesn't run") that it took three calls before it started. You can (dis)prove my idea by adding a "Pause 5 seconds" action after your "Activate" action. If it still activates after this modification, on the first try, then it proves KM really did start it on the first attempt. Your second and third calls were actually ignored by macOS (not by KM) since the app was already running.
I run into your situation all the time, and all I do is start it once, (I have the Activate action BEFORE the loop, not in it) followed by an action to "Pause Until Application X is at the front." And that works for me quite reliably. It always starts, and the loop always ends when the application is at the front. I've never had a failure.
So if I'm right, this isn't a bug at all, it's a design feature of the code that macOS uses to start an app asynchronously. I suspect that behind the scenes KM's engine is using the macOS "open" command, and I suspect that the macOS open command does not "wait until the application is at the front", largely because some apps don't ever come to the front. So it would be a bug for macOS to "wait". If you want to wait for the app to be at the front, you do it in your KM code.
Anyway, it goes without saying that there's a 20% chance I'm wrong. Just try my idea of modifying your loop to prove me right or wrong.
So is that behaviour the "bug" that you mentioned in your macro's title? Is it supposed to do that?
Maybe when you said "Chrome bug" you didn't mean a bug in Chrome, but in your macro....?
Perhaps I'm just missing something, but the way I read your final macro, which you say works only 90% of the time, you are pressing the key B in the NNW app, waiting for NNW to be overlaid by Chrome, and then trying to bring NNW back to the front. I don't understand what that accomplishes. From what I can see, you're just alternating windows without doing anything. What's the intention?
The intention is to open the currently selected NNW article in Chrome for further viewing (later on), then come immediately back to NNW.
We're straying a bit off-topic, but here's some verbosity if you're interested.
Caution: wall of text
NetNewsWire is an RSS reader that displays truncated web articles. There is a feature called "Open in Browser", which opens a link to the currently selected article in the browser. There is also a setting called "open web pages in background in browser". This would send the page to the browser while keeping NetNewsWire in the foreground. This works in Safari, but not Chrome. This bug is documented in the NetNewsWire repository (link), where it has been determined that it is a bug in Chromium (link).
This macro does not emulate the feature perfectly, but it comes close. It doesn't open the link in the background, but it opens in the foreground then immediately switches back. On an M1 Mac, this is almost imperceptibly fast. As stated, this works 90% of the time, but to fix that other 10% by adding a timed pause would make it less fast. The Until loop seems to be working, for whatever reason, so I'm using that instead for now as a workaround.
I don't care to improve the macro at this point, as this workaround is sufficient. If it wasn't, I'm sure there are a dozen other ways I could go about this.
My goal here is simply to point out that {Pause until NNW is no longer at front} followed by {Activate NNW} seems (to me) not to work 100% reliably as expected. Either my expectations are wrong, or this should be brought to Peter, who may or may not know about it or care to fix it (if it is indeed a Keyboard Maestro bug at all).
You've cleared up some things for me. I don't think that was off-topic at all. nor was it a "wall of text." I've seen lots of questions from users that were five times as long as that one.
Now I see why there is a "bug in Chrome." KM can do many things very well, but one thing it can't always solve is visual bugs in other programs, especially when the other programs (eg, Chrome) are not very AppleScript compatible.
I've always told people that "KM can do anything that you can do with your eyes, your mouse and your keyboard." But I don't really mean that KM can fix defects in other programs.
Your question is very legitimate: why doesn't the Activate action always work. Maybe we do need an expert to chime in. It's probably just a timing issue, and I did offer you a way to improve on, and speed up, your "Pause 0.5" action. I wrote,
I run into your situation all the time, and all I do is start it once, (I have the Activate action BEFORE the loop, not in it) followed by an action to "Pause Until Application X is at the front." And that works for me quite reliably. It always starts, and the loop always ends when the application is at the front. I've never had a failure.
If you replace your "Activate NWW" and "Pause 0.5" actions with "Until NWW is in front, Activate NWW" you will find my solution will work faster than 0.5 seconds, and will do so 100% reliably. (I think, and I hope. But I can't test it since I don't have NWW.)
In version 11, the Activate application will wait until the application is at the front, so at least in theory the application will be at the front when it completes.
In practice, what you may be seeing is a level of race conditions between what Keyboard Maestro things is the front application and what the system thinks is the front application, and the system refusing to activate the application when it is deactivating and things like that.
I would suggest you add a short pause action after the first Pause Until to just allow NNW to really deactivate fully. Or, since you know that you are activating Chrome, maybe try a Pause Until Chrome is at the front. (or even both).
I think your race condition theory checks out: I tried increasingly monstrous combinations of Pause Until, Until loops, and If Else checks — the more robust I made it, the better it got, but it would still end up failing one out of every couple hundred runs.
I do think a timed Pause would get the job done, but I was intent on avoiding arbitrary pauses in favor of waiting on computation.
I ended up using AppleScript to (hopefully?) get the system's opinion on what the front application is.
In my testing, this method
• ran thousands of times without failing
• only had to "retry" about half the time
• never had to "retry" more than once
Now I'm off to use this relatively unimportant macro maybe a few times a day.
