Secure Text Entry locked

[vBAq]

Since upgrading to Sierra, Alfred always shows (under snippets) the following red message: "loginwindow seems to be preventing text expansion by locking secure entry".

 

Text expansion does not work. Not only for Alfred, but for every text expansion programme. Even the macOS own text snippets (keyboard system pref) does not work.

 

Now, I thought it was Chrome due to issue 258882. But quitting Chrome doesn't fix it. Rebooting the computer does of course, but I was not able to find another solution so far.

 

Any suggestions?

[deanishe]

Not much you can do apart from avoid the application causing the issue and notify the developers whose bug is causing the problem. 

 

Rebooting is the only way to get snippets to work again, AFAIK. If an app forgets to disable secure entry, you've generally had it.

[vBAq]

I am still at step “find the culprit” right now. Are you saying it could still be Chrome? Quitting the app will not disable secure entry?

[deanishe]

If you open Alfred Preferences > Features > Snippets, it says in red text which application has enabled secure input.

 

 

No idea if it's Chrome. I stopped using it in favour of Safari quite a long time ago (the secure input bug being one of the reasons).

 

Certainly, when Chrome forgot to disable secure input, quitting the application often didn't help. Quitting iTerm does disable secure input, but I have no idea if that's the app tidying up after itself or if the secure input API has been updated to handle that.

 

Edited December 3, 2016 by deanishe

[vBAq]

I have the same message but with "loginwindow" being the culprit. No idea what that is. Is it possible it is still Chrome? 

[deanishe]

loginwindow means the OS itself when you logged in. TextExpander also shows loginwindow when it can't tell which app did it (loginwindow is the parent process).

 

The TextExpander FAQ might help. I think much of it will apply to any snippet expander:

 

https://smilesoftware.com/textexpander/secureinput

[abe]

happened on mine. Confirm Chrome is the culprit. Quit Chrome, "loginwindow seems to be preventing text expansion by locking secure entry" gone

[mikedvzo]

I have had this issue too and if I quit all apps it goes away.  Still yet to figure out the culprit.  

Edited May 22, 2018 by mikedvzo

[illyay]

same here... this is happening to me ALL the time and the only way to fix seems to be to restart my mac! wonder if it has to do with OneLogin... 

[noNameHere]

same here . I have to reboot my mac

[deanishe]

2 hours ago, noNameHere said:

I have to reboot my mac

 

Sometimes, logging out and logging back in works.

[Elliott]

I had luck with this:

1.  --> Lock Screen.
2. Unlock the screen with a password or TouchID

Much faster than logging out for me. Might knock something loose during unlock?

 

macOS Catalina 10.15.1

MacBook Pro (15-inch, 2018)

[JvdMeulen]

On 11/27/2019 at 7:38 PM, Elliott said:

I had luck with this:

1.  --> Lock Screen.
2. Unlock the screen with a password or TouchID

Much faster than logging out for me. Might knock something loose during unlock?

 

macOS Catalina 10.15.1

MacBook Pro (15-inch, 2018)

This worked for me too, probably because of often unlock my mac with my watch.

tnx

[SJ2K]

Snippets suddenly stopped working for me too now that I updated to the Big Sur Public Beta. Same error about loginwindow. Locking/unlocking/rebooting do nothing.

[Alfred User]

Snippets had occasionally stopped working for me as well. After searching for answers I gradually discovered logging out and in, and then later, that merely triggering the screen saver and then re-authenticating (usually with Touch ID) was the fastest way to restore expansion functionality. Recently though it's been happening more often, up to several times a day, and becoming very annoying. Team Alfred - is there anything to be done? It's really starting to get annoying. 🤨 Latest builds of Catalina and Safari.

[Vero]

@SJ2K @Alfred User As explained above by @deanishe, when this occurs, it's down to another app, plugin, or macOS feature locking secure input - and potentially not correctly releasing it when it's done.

 

A few people make reference to Chrome earlier in this thread, and certainly some Chrome plugins (off the top of my head, I know LastPass was an issue at the time) don't correctly release secure input when it's done.

 

Alfred doesn't interfere with the macOS secure input feature and, needless to say, cannot "cancel" or remove another app's secure input, as this would defeat the purpose of that feature.

 

Based on our daily use of Catalina on numerous Macs and generous testing of Big Sur so far, we haven't come across this issue; Snippets are life for me, I don't go an hour without using them, so you can trust we're testing this very thoroughly  

 

I'd take a look at what non-native apps, plugins and helpers you have running on your Mac. Then create a brand new user account temporarily, and ensure that none of these apps or background tools are running there. What behaviour do you see on that second account? 

 

It is difficult to troubleshoot when "loginwindow" is all macOS reports, and much easier when there's an obvious culprit like in the example above where macOS reports that iTerm 2 has secure input, but with the steps above, you should be able to work out what's the cause of your recurring secure input issue.

 

Cheers,
Vero

[spc]

Just an FYI, ran into this problem today - drove me nuts for a while, only thing I can think of having changed over the last few days is a) installing Microsoft Edge and b) Installing the LastPass extension for chrome/edge. Someone above mentioned just trying logging out and reauthenticating - that did the trick! Time will tell if the issue kicks in again though :)

[deanishe]

1 hour ago, spc said:

only thing I can think of having changed over the last few days is a) installing Microsoft Edge

 

Well, that's based on Chromium, and its sibling Chrome is notorious for causing this issue, so it seems likely that Edge is your culprit.

[spc]

On 3/23/2021 at 9:46 AM, spc said:

Just an FYI, ran into this problem today - drove me nuts for a while, only thing I can think of having changed over the last few days is a) installing Microsoft Edge and b) Installing the LastPass extension for chrome/edge. Someone above mentioned just trying logging out and reauthenticating - that did the trick! Time will tell if the issue kicks in again though

Further to this, I actually tracked down the problem to Bitwarden. Can't find anything it the Bitwarden preferences to change that setting, so looks like I'm back with LastPass for the foreseeable.

[deanishe]

31 minutes ago, spc said:

I actually tracked down the problem to Bitwarden

 

The application or a browser extension? And if the latter, in which browser?

 

The Bitwarden app having the issue would certainly make sense, as it's based on Chromium—the worst offender for not releasing Secure Text Entry.

[DjCoke]

I do not hope that I making myself a hijacker of this topic, but I have this problem as a new user. I am using mainly Chrome for my webapps for work. And I use the plugin of Dashlane. I suspect Chrome or the plugin to interfere.

 

Is there no way to disable the locking feature of OSX? It is very annoying to have to reboot the mac every time this happens. There is also no evidently sign when this occurs. Rebooting Chrome btw doesnt help at all or to close off Dashlane for that matter or one or both or in any particular way other then to reboot completely.

 

[Vero]

@DjCoke Welcome to the forum

 

In Alfred, you can see whether the secure entry is locked by a third-party in the Features > Snippets preferences, where it will appear in red like this:

 

 

It's not possible for Alfred or any third-party to override this, as it's a security feature in macOS and giving other apps a way to override it would invalidate the entire purpose of protecting you while you're typing sensitive information such as passwords.

 

Rather than rebooting blindly every time the issue occurs, try to work out which app or plugin is the source of the issue. I would then very much encourage you to report it to the maker of the problem app/plugin, as this is the real way this should be resolved. If it's the Dashlane plugin, it should release the secure entry as soon as you're no longer in a protected field.

 

Cheers,
Vero

[alon85]

I'm seeing the same error with "Process ID 1776" as the culprit.  However, I don't seem to have any process with that ID running on my mac.

 

Not sure how to dig further as to how to fix this.

[Vero]

7 minutes ago, alon85 said:

I'm seeing the same error with "Process ID 1776" as the culprit.  However, I don't seem to have any process with that ID running on my mac.

 

Not sure how to dig further as to how to fix this.

 

The error message usually makes it easy to identify which application has locked secure input. If Alfred reports that "loginwindow seems to be preventing text expansion by locking secure input" or a random process number, it's likely that Alfred is unable to tell which application is using secure input.

This can be because macOS itself has left the secure input enabled (e.g. when you've recently logged into your Mac, or after waking your computer and typing your password). This can be resolved by restarting your Mac, or logging out fully and logging back in.

If the issue occurs frequently, try launching a minimum number of apps/services on your Mac, and re-launching apps one by one, allowing you to establish which app or service is locking secure input by process of elimination. Note that browser plugins (e.g. password managers) can be the cause, so enable plugins one at a time to test them.

 

Cheers,
Vero

[Doberman]

I restarted the system and having the same issue. Any suggestions?