BTT does NOT switch to old keyboard implementation even if it is checked

Bug Reports
1

Hi there,

Am still having a few issues with keyboard shortcuts being non-responsive secondary to secure input activation. Per the settings, it's supposed to revert back to old keyboard implementation if BTT detects secureinput is activated; however, it does NOT and keyboard shortcuts remain unresponsive.

If I physically tick off the "always use old keyboard implementation", keyboard shortcuts will then work accordingly. This gives me the impression that the "automatically switch" option is NOT working as it should.

Your support would be helpful.

Thanks!

2

I believe I have found a related issue. This should be fixed in the next alpha version later today. (v2.504).

3

v2.504 alpha is now online (get via check for alpha version updates). It would be great if you could test whether that resolves your issue too.

4

Thanks. I'm having issues updating to the latest Alpha - it can find v2.504 but will not proceed with the update as it did previously. Your help here would be great!

An error occurred while downloading the update. Please try again later.

Cheers!

5

Ah sorry, update should now work.

1 Like
6

Still no dice on this issue - does not seem to automatically implement the old mechanism. PS - I was eggplantsplz on github and we had a very lengthy discussion regarding cessation of keyboard shortcut functionality. Not sure if it's still an isolated problem with regards to my machine or if others are having similar issues.

Secureinput seems to get activated by any active window... and shortcuts do not work if I don't check the "use old implementations."

Let me know if you need anymore information from me, would be happy to help sort this out.

7

Ah ok, then the fix included won't help you unfortunately.

In your case it probably wouldn't make a difference anyways because secure input seems to constantly be enabled on your system for whatever reason
:confused:

We never figured out what is causing it to be always enabled, correct?

8

Correct... we weren't able to figure it out unfortunately. Even now, it doesn't seem to be activated by anything yet it still shows up as such:

image
image.jpg1010×688 161 KB

Wondering what's going on.. I unfortunately don't have the luxury of a system reformat at this time either.

9

Mhm interesting, if it's null, the system seems to return the process identifier that holds the secure input lock, but that process doesn't seem to have a name.

I'll add the identifier to the info, then you would be able to look it up via Activity Monitor.

10

It may also be interesting whether other apps that require secure input to be disabled work correctly on your machine (e.g. http://www.trankynam.com/atext/ ).

11

I think you're onto something here: atext will not work, and is similarly an issue with secureinput:

image
image.png776×446 52.2 KB

Thoughts on how to further explore this? Seems like something is causing Secure Input to hang. I can provide a list of all running applications if that would help?

12

Based on the BTT window, it is most often enabled by "loginwindow" even beyond the login screen.

13

I think the loginwindow thing is a bug in BTT because I didn't handle the case when there is no name for the process identifier that gets secure input. (thus it's never updated)
In the next alpha BTT will show the process identifier, this may help identifying the process.

14

Ah sounds good. I'll keep an eye out for the next alpha.

15

Updated to the alpha and restarted. Loginwindow persists as the hangup app (PID: 101). Can confirm that secureinput seems to always be on again. (can't use FN keys for keyboard shortcuts)

image
image.jpg1140×706 171 KB

16

I guess something is broken on your macOS instance then because loginwindow really shouldn't do that :frowning: Maybe report it to Apple, I will also do that.

You don't have any tools installed that somehow enhance the login window, correct?

17

Have you checked whether PID 101 belongs to loginwindow? (you can see the PID in the activity monitor)

18

I found some notes for other apps where users encountered similar problems. It seems like most of the times when macOS says loginwindow is causing this, in reality it is some other app where a bug causes secure input to stay active.

19

Ugh, that's disappointing. I might have to figure out a time to do a complete reinstall then... which will be entirely cumbersome to do.

image
image.png1696×116 13.9 KB

Yes, it looks like loginwindow is indeed the app in the activity monitor. Do you have something similar in yours? I don't run any other apps that alter login settings.....

20

Could it have anything to do with Security and Privacy settings in System Preferences?

Edit: so at this point, I've conceded that I likely have to complete an OS reinstall and re-configure my Mac one app at a time. Short of doing that, do you have any other suggestions as to how we can pinpoint the particular issue? I could theoretically deep uninstall one app at a time and see if any of them will fix the issue, but this may be time consume and very onerous....