I've downgraded to 4.434 which doesn't have this issue. The latest version 4.454 has broken all of my automations that involve pasting and typing text. It seems like everything is going way too fast, but the specific behavior I'm seeing goes like this.
- Trigger a keyboard shortcut that fills the clipboard from another program
- attempt to paste the contents of the clipboard
- the previous contents of the clipboard are pasted or typed rather than what was just loaded into the clipboard
- multiple new strings are loaded into the clipboard, but the old text continues to be pasted
- adding a delay sometimes helps, but does not always work
Device information:
- Type of Mac: MBP 16-inch, 2023
- macOS version: 14.4 (23E214)
- BetterTouchTool version: 4.454
Ah that's interesting. 4.454 disables an automatic delay between keystrokes. In my tests it was almost never helpful / necessary and caused various issues. However I see that especially copying to clipboard takes a moment.
Adding an async delay should solve the issue, but you can also activate the old behavior in the settings:
However as this is probably common for cmd+c, I'll internally handle that with the next version later today. In the future cmd+c will block execution until either the clipboard content has changed or until a small delay has passed.
I was adding async (also tried sync) delays of up to 1 second before and after filling the clipboard which did not consistently fix the issue. There was also a sequence where I would tab through 4 different fields, each with its own delay, but on each field, the same old contents would get picked up even though it had changed 4 times.
It would seem like if this were a delay issue only, once the automation finished, new clipboard contents would be in the clipboard. But that is not the case.
For my specific use case, I’m sending alt-v to tell a chrome shortcut to use JavaScript to fill the clipboard with some specific text from another site, so an automatic delay on cmd-c wouldn’t help me (but might help others). Perhaps some kind of delay or synchronization when accessing the clipboard contents would cover more corner cases.
As a side note, I always was interested in being able to configure a default delay between keystrokes on a per shortcut/automation basis which saves me from littering the definition with delay steps. This is something available for my keyboard macros for example.
Could you check whether your automations work again with 4.456? I have added back an automatic delay for cmd+c shortcuts (it now waits either 0.3 seconds or until the clipboard content has changed, depending on what's faster). I can't think of any other change that would influence this
For the delays it's important to use the async delay option because macOS 14.4 has introduced a change that prevents the clipboard from changing while BTT is executing a "blocking" delay.
Tested with version 4.457 as that was the latest. Let me know if I should retest with 4.456.
Without the "add small delay" option selected, the automations don't work at all. Maybe this makes sense as I'm using alt+v to fill the clipboard, not cmd+c. But even with the option selected and adding 4 second async delays after filling the clipboard and before pasting, it still doesn't grab the clipboard content in some automations.
If I open the clipboard manager after the automation runs, I can see that BTT has all of the clipboard contents I would expect, but it gets stuck pasting the wrong thing.
Let me try to put together a video showing the behavior, it's quite unexpected.
Here is the odd behavior. Notice at the contents at top of the browser window in the green bar. This is my chrome extension indicating what content has filled the clipboard. Until the end, all actions you see are automated by BTT. There is a 3 second async delay step before each paste text.
You notice for the first few paste actions, the text is correct, but once I get past the address field, only the address is pasted. You can see in both the green bar and in the clipboard manager at the end that different data is loaded into the clipboard.
At the end, I manually press cmd+v to show that native pasting also seems to have the wrong content in the clipboard even outside of automation.
very strange, you are sure it‘s working with the previous versions? (macOS 14.4 changed various things about the clipboard, could also require an update from the extension)
Positive it works as expected with version 4.434 - just replaced and tested again. There is a difference in the automation rules though as every time I downgrade, the actions for the triggers revert to the state they were in before I upgraded to the latest and started fiddling with everything. Are you doing something like excluding actions with a BTTLastUpdatedAt newer than the release date of the running version?
The other nuance I can think of is that the way this automation is arranged is as a series of Named Triggers. This allows me to do things like wait for some text to appear on the screen, attempt to click that text and if the text is found continue, otherwise exit the automation sequence (Found Text / Did Not Find Text).
And in that sequence where pasting begins to fail in the video is after the first paste happens within a named trigger. All the other pastes occur in a "once per named trigger" fashion. So I wonder if there is a sync issue going on with clipboard interaction within named triggers.
every version in BTT keeps it‘s own database (to make downgrades possible as database migration is a oneway path), thus reverting the version also reverts to that version’s database.
I’ll check whether I can reproduce anything when trying with named triggers!
Another data point for you. I broke the sequence of clipboard interactions to call a series of the same named trigger (paste dance), which contained only, alt+v, delay 3 seconds, paste text within the problematic named trigger.
This still failed as previously described, but when switching from paste text to type text. Everything worked as expected.
ah are you always using the paste text action to paste? or did you also try with just sending the cmd+v shortcut?
(my tests always used just cmd+v, maybe I need to look at the paste text action instead)
You're right, when I send cmd+v instead of the paste action it works just fine. I can then force everything to work by adding a 0.1 second delay after filling the clipboard or checking the "small delay" option.
I got into the habit of using the paste text action because many websites either block cmd+v or don't like it when text magically appears, so often I switching between paste/type text and the paste action makes that a bit easier.
then I should be able to reproduce it, I’ll have a look!
Would be great if you could test v4.458. I made some changes so the paste text action needs to rely less on timing. In my tests this seems to work better now.
Seems like that fixes the paste text action, though I still need to use the "small delay" or manually add a 0.1 second delay before pasting to avoid the strange issue. I would guess this is related to me filling the clipboard via the chrome extension though.
that's good, I hope now at least everything becomes a bit more explicit. I'll soon add an option to define a default delay per action sequence.
