Often, but not always, the first instance does not succeed (capturing the title and the URL of a YouTube video)
At the second instance using the macro, it ALWAYS works correctly.
This can also happen with similar macros.
The pause is 1.5 seconds which should be enough.
Thankful for any input.
/okn
How does it not succeed? What does it do?
Every time that macro runs it will set the system clipboard to include the date and time and whatever is reported by the front browser as the title and URL.
So when it fails for you, how does it fail? What is different from expectations.
Well, the difference can be seen in the extra image
at 10:56, LINE 21
nothing much was processed, except for the Date & time, with the ◇ … ◇ delimiting the title.
the same macro ran again at 10:57, LINE 17 - 19
everything is fine.
And this happens about 2 times out of 10.
At the second try, it ALWAYS works correctly.
What could be the cause?
macOS Tahoe 26.2, KM 11.0.4
OK, so the tokens are returning no text.
My guess would be that the web page hasn't loaded.
FrontBrowserTitle basically asks the front browser (via AppleScript) to run the JavaScript document.title on the front tab.
It will return nothing if either:
This means the browser needs more time, 1.5 sec / 2 sec to respond.
However, what is still unclear to me,
The webpage has been loaded and is clearly visible, when executing the macro.
How to give the browser more time to respond to the script?
(And in the original macro the pause of 1.5 sec is probably of no use.)
/OmarKN
Browsers display web pages before the page has finished loading -- that's why we're told to always include width and height in our img tags, so the browser knows how much space to leave on the page while it continues to download the image.
Even after the page has fully loaded, if the browser is "busy" it may take longer than KM's 0.9 second "timeout" to respond to the Token request. That "business" may even be because the browser is reloading page elements.
Try putting this in as the first Action of your macro:
Also:
The pause is in the wrong place -- it needs to be before the "Set System Clipboard" Action. Try that if the wait-for-loading method fails.
I'll check this on several macros (Wait for Front Browser…) with 1 and 2 sec, and report back on it…
You could likely just Pause Until action the Text condition FrontBrowserTitle token is not empty (or check both), or contains something you expect (the parts that don't change in the title/URL for example, if there are any).
Here I want to show (screenshot1) the macro with this TEXT & URL condition and still there is no result,
except when the macro is repeated.
(This could have been simplified, I realize now.)
Screenshot2 shows the result of 2 trials, A and B.
Question
Is there maybe a time-out of sorts? Can the time for the macro to find TTL / URL / TEXT be increased somehow?
Since upgrading to macos 26.1 (now 26.3) the Mac mini is - sometimes - not always - sluggish, with the famous beachball. (I've tried to adjust some macos settings.)
Any assistance will be much appreciated,
OmarKN
After posting the above, I now also added
Wait For Front Browser to Finish Loading
3 sec
Let's see what happens!
Yess -- see the manual.
As a start a timeout increase to 2.0 (or more)
but keeping the 2nd line as is?
defaults write com.stairways.keyboardmaestro.engine TokenTimeout -float 2.0
defaults write com.stairways.keyboardmaestro.engine ForceSynchronousTokens -bool YES
This has to be tested…
This sequence:
is displaying the tokens and then waiting until they are not empty.
That seems to be backwards.
Before leaping in, confirm that is the problem. All you need to do is time the Action:
If it is a Token timeout issue you'll see that when a URL is displayed the time will be considerably less than 900 milliseconds, but when the URL is empty the displayed time will be just over 900ms.
(I don't know if %ActionResult% works here -- the Action itself may be "OK" even if the Token evaluation within the Action fails. And I can't force a Token timeout to find out!)
