Key Sequences Fail to Work When Advanced Configuration Page is Closed


  • Unable to update to the latest alpha version (Nothing happens when clicking install and restart when updating to alpha version); using the latest stable version.
  • System has been rebooted.

Describe the bug
Key sequences that are set up with specific conditions work only when the advanced configuration page is open. As soon as the configuration page is closed, the key sequences stop functioning.

For example, a key sequence is set to trigger the shortcut command + T when the key T is pressed in the browser, provided the focused element's role is AXWebArea. This sequence works as expected when the configuration page is open for debugging. However, it ceases to function once the configuration page is closed.

Affected input device (e.g. MacBook Trackpad, Magic Mouse/Trackpad, Touch Bar, etc.):


If applicable, add screenshots to help explain your problem. (You can just paste or drag them here)

Device information:

  • Type of Mac: Apple Silicon
  • macOS version: 14.4.1
  • BetterTouchTool version: Version 4.469 (44680)

Additional information (e.g. crash logs, related issues, etc.):

Update: it somehow magically working now. Will update again after more usage. Thanks for your attention!

I've been using the trigger for a couple of days, and I'm noticing some inconsistencies. Sometimes the key sequence works just as I expect, but other times it doesn't seem to respect the trigger condition.

For instance, it should trigger Cmd + T only when the focused element isn't a textfield. However, there are times when it does this even if the focused element is a textfield. This indicates that the assigned action is working, but the condition doesn't always hold, even though it sometimes works correctly.

The issue often arises when the laptop wake up from sleep, and I already set to true for restart BTT after wake from sleep.

Currently, the temporary fix i discovered is that i need to invoke BTT window once which will make the trigger work correctly.

Could you help me figure out how to permanently fix this please? Thanks!

are you using this with a specific app? or does it happen in general? Sounds like a similar issue that @Frank1 encounters.

I assume that for some reason BTT doesn’t receive notifications for the focused element change anymore. I’ll check whether I can somehow reproduce it.

Thanks for your quick response! Yes, i am using this trigger specifically for Arc browser.

I have attached a screenshot for reference.

Detailed condition as code:
active_app_name == "Arc" AND (NOT (currently_pressed_keyboard_keys CONTAINS "56," OR currently_pressed_keyboard_keys CONTAINS "55," OR currently_pressed_keyboard_keys CONTAINS "58," OR currently_pressed_keyboard_keys CONTAINS "59,")) AND focused_window_x != 480 AND focused_window_y != 274 AND focused_window_width != 750 AND (NOT (focused_element_role == "AXComboBox" OR focused_element_role == "AXTextArea" OR focused_element_role == "AXTextField"))

Yes, I think that's a similar problem to the one I have.

It's probably not much use, but I've found out:

The problem seems to be with the (text) fields.

If what you want to do can be expressed only with the "subrole" (instead of "focused element role", then it works much better, but not perfectly.

It works perfectly if no fields are used at all (only window names etc). At the moment I do it like this. After all, I know in which field I use the key sequence. The disadvantage is of course that the same key sequence cannot do different things in different fields.

Hi @Andreas_Hegenberg . Not sure if this is relevant to BTT, but in Activity Monitor, I always notice there is a process called cursorUIViewService is not responding.

Also, the issue of assigned actions not respecting the advanced condition mentioned earlier seemed not limited to a particular app. For instance, i have a global action configured as follows:

The condition is: if pressed there's no active window for the current app after pressing command+w then perform command+h (to automatically hide the current app which ultimately switch focus to next app).

The action mostly working fine, but similiar to my earlier issue with Arc, some times it will proceed and perform command+h even there is indeed active window, i.e chrome closing tabs, it will hide the chrome even when the active window is not empty.

I am one step away from my perfect setup, looking forward to your advice. Thanks for your attention.

for these I‘dd add some (async) delays inbetween. The system takes a moment after closing a window to send the change notification to BTT

More update:

  • Cmd+w issue has been fixed, but the issue with Arc triggers persists
  • I realise the issue only happens after wake up from sleep.
  • It is not necessary to bring BTT window to the front, change focus to other window/app and change back to Arc also do the trick. i.e. Cmd+tab twice. And all triggers will work correctly until next time wake up from sleep.

The async delay you suggested unfortunately didn't fix this issue. What puzzles me the most is the fact that BTT is able to recognize the app == Arc rule, but not able to recoginze the focused element role != AXTextField rule.

Any advice? Thanks.

that’s not very surprising, the focused element observation is a LOT more complicated than the app name observation :wink:

I‘ll check whether there is anything that can be reset after sleep

@Andreas_Hegenberg Sorry, but that's not the problem. At least not for me. I'd like to explain exactly what the problem is, but unfortunately I can't. Maybe this observation will help. If the cursor changes from field A to field B, but nothing else changes, BTT often does not recognize this field change. The condition remains true or false (green or not) as it was before the field change.

However, if something else also changes too (except the field), for example the name of the window, then the new field is recognized. :man_shrugging: Does this help?

@frank1 does the value update here correctly?

If only the name of the field changes, then not. If something else also changes, the new field is also recognized.

Edit: If more than the field changes in this window, then everything is fine. :slightly_smiling_face:

do you have a concrete example for this? I think you encountered it in a writing app, right?

To exclude the possibility that it is just a Scrivener problem, I have also tried this with Devonthink, where the same problem occurs. Unfortunately, I don't know how it is with other apps ... but I can give it a try now.

Mm, I just tried that with Macjournal. It's a similar app to Scrivener or Devonthink with different text fields.

In Macjournal BTT recognizes every text field even if nothing else changes. Then something is obviously different with Scrivener and Devonthink. :thinking:

the problem is BTT relies on notifications sent by the apps to update the focused element - an alternative would be to poll the state of the focused element, but that would obviously create more cpu usage.

All standard macOS apps should support these notifications because Apple implemented them in all standard UI elements. However some multiplatform apps might not support them correctly. It sounds like both Scrivener and Devonthink are such multiplatform apps.

One thing I could easily do is add an per-app option to switch between polling and notifications.

If you can easily add this option, I would love to try it out. That way, everyone could choose whether they want to spend more resources or not. :slightly_smiling_face:

I have added an option for that in 4.515 alpha:

The default polling interval is 1.5 seconds

Do I understand correctly that if the cursor is in the "correct" field, it should not take longer than 1.5 s for BTT to recognize the field? Unfortunately, this is not the case.

Here the cursor is in the field "AXTextField". The condition is fulfilled. But BTT still shows the last field "AXOutline" ... no matter how long I wait.