I'm no longer able to record the UI path for Firefox and Edge (and possibly other apps) when using the action "Access / Interact With / Click Specific Ul Element". I'm not sure since when because I haven't used that function in a while, but previously it was working for sure, since I have configured working trigger+action for Firefox which now stopped working. Once I try to select any item only the whole window is being recognized and if I try to select the buttons in the top left - this is also working.
It was working on BTT 6.040 and previous versions, but recently I've updated to versions > 6.040 and today I've noticed that my trigger is not working and started troubleshooting which led me to this observation that the path cannot be recorded.
By the way once you activate this UI element selector (after clicking "Choose Ul Element") there's no real way to cancel the operation - your path is always replaced with something, either the "Cancel" element itself or with the selected element.
Did you in the past have some other accessibility related tool active? I don't think there has been a change to this since 6.040, however e.g. Firefox (for performance reasons) usually doesn't allow UI scripting access unless e.g. a screen reader / voice over is active. I think I can force this "voice over / screen reader" state, but it was not done before either.
This is the "issue"! When the app Homerow is running I'm able to record these paths and the trigger is working. Thank you!
About the "Cancel"/stop of the recording, am I not doing something right?
That is definitely the reason. I'll automatically enable that state temporarily whenever the interact with ui element action is being used (and deactivate it right afterwards because having this active all the time is really a performance killer - if homerow has this active all of the time, you will definitely have some noticable performance drop in Firefox)
Homerow is usually running all the time (I'm having it for at least a year) but I haven't found any performance issues and I consider myself a heavy user (200+ open tabs with at least 2-3 YouTube tabs with paused videos and one playing). I'm not going to lie Firefox is usually in the top 10 processes by CPU and Memory but no performance issues at all. Maybe the reason is that Homerow is really "active" when I trigger it and maybe only then it activates its "Enable AXEnhancedUserInterface" and "Poll AX Attributes" which is the heavy stuff? Could there be something else, since I do not activate Homerow all the time?
I've tested what you suggested to "Enable AXEnhancedUserInterface", which is working, but now for some reason even without Homerow running and without BTT's "Enable AXEnhancedUserInterface" and "Poll AX Attributes" enabled I can record the UI path, even after BTT restart (with Homerow closed)
If any app (e.g. homerow) has activated the flag and not deactivated it again, then it will continue to work until you restart Firefox.
BTT always immediately disables it again after using the flag (it is used in various window snapping related actions).
If you don't mind the higher cpu usage, it is fine to have this enabled all the time - but especially for Browsers and even more so for Firefox the difference is significant. The problem with browsers is that they have to make the whole website AX tree available and compute it all the time when loading a webpage - and that tree can be HUGE.
As always you are right - restarting FF, solved this. Thank you!
Regarding the "Cancel"/stop of the recording, am I not doing something right? Is there a way to really cancel without overwriting the path? This could be an issue, since the user might not have backup of this path and can accidentally overwrite it, respectively to break it
Andreas, I've just updated to BTT: 6.334 and while now the "Cancel" element's path is not recorded (it is even not selectable) and the AX Path is not replaced with Cancel's path (previous behavior) now the latest hovered element's path is replacing the existing one once I click Cancel.
- this is also working.
