Alfred won't show in Monterey after using Secure Entry field [Fixed in 4.6.4 b1291 pre-release]

[Vero]

5 hours ago, godbout said:

i've made a video but too big for here.

 

Could you pop an email to our info@ address with a link to it? Stick it on iCloud or Dropbox temporarily? 

 

Also, if Alfred *crashes*, could you please send any crash logs? I haven't heard of an actual Alfred crash in a very long time so I'd be very interested in taking a look at any logs you have from Console.

 

Cheers,
Vero

[godbout]

done for the video. i could have done that and linked here actually. guess i'm still a sleepyhead. 

 

regarding the crash i'll send logs next time it happens. the last time it was when i used the Alfred Media Player. thanks! 

Edited November 22, 2021 by godbout

[Vero]

48 minutes ago, godbout said:

regarding the crash i'll send logs next time it happens

 

If there's a crash, the log will still be available in Console under the Crash Logs header in the sidebar even if it happened a little while ago.

 

I'll take a look at your video and get back to you if we need more information.

[Vero]

@godbout I've watched your video and it's very difficult to make out what you're doing without explanation or a view of your keypresses.

 

It looks like there may still be something interfering with your hotkey combo; If you change Alfred's hotkey combo to something obscure that definitely isn't used by another app you're using, what behaviour do you see?

 

Cheers,
Vero

[godbout]

hmm. so what would be a better way? i can an app that shows the key pressed next time? (although that's going to steal keyboard presses too, might make it even worse :D)

 

i thought the video was pretty clear though. as explained in the email, i toggle Alfred on and off while Xcode is in fullscreen. you see Xcode UI flashing when it happens. it flashes because Alfred takes over, but not on the right (current) space, which i show by switching to that space (and we see that Alfred showed up wrongly on it).

 

anyways, will try something better next time then. thanks.

[Vero]

@godbout If you change Alfred's hotkey combo to something obscure that definitely isn't used by another app you're using, what behaviour do you see? As I said, it still feels like a hotkey conflict so the first thing to try is to change the hotkey away from the coveted Cmd + Space or anything that could be used by another tool on your Mac.

[fonginator]

@VeroI experienced the loss of hotkey problem yesterday. It was 100% reproducible but only when Microsoft Teams presents its login prompt. I am pretty sure this has to do with Secure Keyboard Entry or something similar because when I was prompted for my password by the app, my Alfred hotkey (Control-Space) stopped working until I used Spotlight (Command-Space) to bring focus to Alfred, quit Alfred then re-launched it via Spotlight. However, every time the password prompt came up, Alfred's hotkey stopped working.

 

OTOH, Alfred did not crash. It simply stopped responding to the hotkey shortcut.

 

And FWIW, I had to disable Secure Keyboard Entry in iTerm2 or else Alfred's hotkey stopped working altogether.

 

[Vero]

There are two unrelated issues being discussed in this thread concurrently, so I'll first respond to the issue of Alfred's hotkey not triggering the window.

 

A small number of users on Monterey seem to be experiencing an issue where the Alfred hotkey cannot be used when certain apps and fields are in focus. This may be due to a change in Monterey's security features; In this case, it looks like it aims to stop apps from simulating being a secure input field. 

 

When this occurs, @itabraham highlighted that Console presents this message:

 

On 10/28/2021 at 7:08 PM, itabraham said:

WindowServer	CPS: Denying Alfred the right to be in front because secureTextInput is active and this process doesn't have secure text mode enabled, and this request was not caused by user activity

 

We've tested a variety of scenarios in Monterey using 1Password, Keychain, Safari with a password field, and a few other apps to trigger secure input mode, and Alfred's hotkey has worked normally in every instance. As we've been unable to replicate this, we'll need the help of those who are affected to establish in what scenarios this can happen.

 

When you encounter this scenario where the Alfred hotkey can't be used:

• Which apps are in focus right now? Which apps are running on your Mac?
• If it's an app with plugins (e.g. Chrome), what happens if you disable or completely remove the plugins? Bitwarden seems to have been one of the potential interfering parties so far, perhaps Microsoft Teams?
• Does Console show the message quoted above?

If you're able to help us work out when/how this happens, as Andrew said earlier on, we may be able to make the WindowServer aware that Alfred's search box popping up is "caused by user activity". 

 

@godbout Given your issue is different to the above, can you please get back to us by email to keep this thread focused? 

[Stephen_C]

19 minutes ago, Vero said:

A small number of users on Monterey seem to be experiencing an issue where the Alfred hotkey cannot be used when certain apps and fields are in focus

Please excuse the intrusion—especially if you feel it's irrelevant, but… I have posted previously about macOS (both Big Sur and Monterey) falsely considering secure input is enabled. Aside from doing what you suggest to see which apps are at fault I've discovered this can often happen if you have a MacBook Pro which unlocks from an Apple Watch. On many occasions when I've discovered the problem (usualy because my Typinator text expander app stops working) I can instantly fix the problem by locking my MacBook Pro (using Alfred, of course!) and then unlocking it using Touch ID. I reported the apparent bug to Apple at least two years ago.

 

I mention this only in case it helps anyone who may be in a similar position (i.e., unlocking with an Apple Watch).

 

Stephen

[superficial]

I have this exact issue too. I have the same phenomenon in both Safari and Brave browsers (haven't tried others). It appears (to my uninformed self) that Mac OS is probably blocking Alfred when in a password field, but there's then a second phenomenon whereby even after shifting focus / tabs, the hotkey (Cmd+space) doesn't activate Alfred.

 

However, if I 'toggle Alfred' from the menu bar TWICE (presumably once to turn the invisible instance off, and then once to turn it back on again), it reappears, and my hotkey works again. In fact, if I toggle it off using the menu bar, I can summon Alfred with Cmd+Space, as usual.

 

Interesting re: Apple Watch. I'm using an Apple Watch to unlock, although I tried locking the Mac and unlocking with TouchID and the same things happened. Perhaps if restarted and logged back in again without using my watch it might be different, but the fix you mention doesn't seem to help. Also the same with/without BetterTouchTool running. 

 

To be honest it's not a major issue for me. It's just a weird bug. 

 

I get the Console message above, and also this one: 

Since sending application [sess=100005 pid=903 uid:501,501,501 g:20,20 pV:2298] is not permitted to send this AppleEvent to this process, returning an errAEEventNotPermitted reply.

 

Alfred 4.6.1 [1274], no powerpack

MacOS 12.0.1

Safari Version 15.1 (17612.2.9.1.20)

Brave Version 1.32.113 Chromium: 96.0.4664.45 (Official Build) (x86_64)

2018 MacBook Pro 13" w touchbar

[fonginator]

@Vero I've found a way to reproduce the loss of Alfred's hotkey almost 99% of the time; there are random times when this does not trigger the problem. And yes, I do get the following console message when this occurs:

 

CPS: Denying Alfred the right to be in front because secureTextInput is active and this process doesn't have secure text mode enabled, and this request was not caused by user activity

 

In my case, I have MariaDB installed via Homebrew so the easiest way for me to trigger this problem is by getting mysql to prompt me for a password:
 

❯ mysql -u root -p
Enter password:

 

Now if I attempt to trigger Alfred with my hotkey (Control-Space), nothing happens even after I dismiss the password prompt with Control-C or by entering a password. I have to re-launch Alfred in order to get the hotkey working. However, interestingly, keyboard shortcuts for my various workflows still work, even at the password prompt that disabled my Alfred hotkey.

 

I am running iTerm2 3.4.12 (Secure Keyboard Entry is disabled) on macOS 12.0.1 with Alfred 4.6.1 [1274].

 

I've noted that the same behaviour sometimes occurs with some other password prompts, too, like the one that the Microsoft Teams app displays when it wants you to login.

 

 

[Com30n]

I have the same problem: yesterday I upgraded my mac to Monterey and found that

alfred stops responding to any shortcuts after I try to use any password field in Chrome.

 

Steps to reproduce:

1. Install the lastpass extension for Chrome
2. open the extension
3. click in the master password field

4. do not remove the cursor from the field, try to open the alfred query window

(maybe you will need to repeat 2 and 3 step several times)

 

and after I do that, I can't use alfred until I open it again in finder -> applications -> Alfred 4.app

 

P.S. I have the following log in the Console.app (note that when I tried to open Alfred using hotkeys, it added "Alfred Running a query in qos line 0x19" in the log, but the alfred window was not shown):

default	13:49:32.982954+0300	runningboardd	Assertion did invalidate due to timeout: 380-340-3933 (target:[app<application.com.runningwithcrayons.Alfred.181527167.181527208(501)>:7832])
default	13:49:32.983006+0300	runningboardd	Assertion did invalidate due to timeout: 380-340-3934 (target:[app<application.com.runningwithcrayons.Alfred.181527167.181527208(501)>:7832])
default	13:49:33.105217+0300	runningboardd	Calculated state for app<application.com.runningwithcrayons.Alfred.181527167.181527208(501)>: running-active (role: UserInteractive)
default	13:49:33.105254+0300	runningboardd	[app<application.com.runningwithcrayons.Alfred.181527167.181527208(501)>:7832] Ignoring jetsam update because this process is not memory-managed
default	13:49:33.105508+0300	runningboardd	[app<application.com.runningwithcrayons.Alfred.181527167.181527208(501)>:7832] Ignoring suspend because this process is not lifecycle managed
default	13:49:33.105808+0300	runningboardd	[app<application.com.runningwithcrayons.Alfred.181527167.181527208(501)>:7832] Ignoring GPU update because this process is not GPU managed
default	13:49:34.371692+0300	runningboardd	Invalidating assertion 380-372-3748 (target:[app<application.com.runningwithcrayons.Alfred-Preferences.181527173.181527178(501)>:7837]) from originator [daemon<com.apple.WindowServer(88)>:372]
default	13:49:34.376950+0300	runningboardd	Acquiring assertion targeting [app<application.com.runningwithcrayons.Alfred-Preferences.181527173.181527178(501)>:7837] from originator [app<application.com.runningwithcrayons.Alfred-Preferences.181527173.181527178(501)>:7837] with description <RBSAssertionDescriptor| "AppNap adapter assertion" ID:380-7837-3953 target:7837 attributes:[
	<RBSAcquisitionCompletionAttribute| policy:AfterApplication>,
	<RBSDomainAttribute| domain:"com.apple.appnap" name:"Enable" sourceEnvironment:"(null)">,
	<RBSDomainAttribute| domain:"com.apple.appnap" name:"PreventTimerThrottleTier4" sourceEnvironment:"(null)">
	]>
default	13:49:34.377172+0300	runningboardd	Assertion 380-7837-3953 (target:[app<application.com.runningwithcrayons.Alfred-Preferences.181527173.181527178(501)>:7837]) will be created as active
default	13:49:34.381504+0300	runningboardd	[app<application.com.runningwithcrayons.Alfred-Preferences.181527173.181527178(501)>:7837] Ignoring jetsam update because this process is not memory-managed
default	13:49:34.389417+0300	runningboardd	[app<application.com.runningwithcrayons.Alfred-Preferences.181527173.181527178(501)>:7837] Ignoring suspend because this process is not lifecycle managed
default	13:49:34.389674+0300	runningboardd	[app<application.com.runningwithcrayons.Alfred-Preferences.181527173.181527178(501)>:7837] Ignoring GPU update because this process is not GPU managed
default	13:49:34.396933+0300	runningboardd	Calculated state for app<application.com.runningwithcrayons.Alfred-Preferences.181527173.181527178(501)>: running-active (role: UserInteractiveNonFocal)
default	13:49:34.398554+0300	runningboardd	Invalidating assertion 380-7837-3736 (target:[app<application.com.runningwithcrayons.Alfred-Preferences.181527173.181527178(501)>:7837]) from originator [app<application.com.runningwithcrayons.Alfred-Preferences.181527173.181527178(501)>:7837]
default	13:49:34.627016+0300	runningboardd	[app<application.com.runningwithcrayons.Alfred-Preferences.181527173.181527178(501)>:7837] Ignoring jetsam update because this process is not memory-managed
default	13:49:34.634098+0300	runningboardd	Calculated state for app<application.com.runningwithcrayons.Alfred-Preferences.181527173.181527178(501)>: running-active (role: UserInteractiveNonFocal)
default	13:49:34.628133+0300	runningboardd	[app<application.com.runningwithcrayons.Alfred-Preferences.181527173.181527178(501)>:7837] Ignoring suspend because this process is not lifecycle managed
default	13:49:34.635085+0300	runningboardd	[app<application.com.runningwithcrayons.Alfred-Preferences.181527173.181527178(501)>:7837] Ignoring GPU update because this process is not GPU managed
default	13:49:34.638147+0300	runningboardd	[app<application.com.runningwithcrayons.Alfred-Preferences.181527173.181527178(501)>:7837] Set AppNap state: <RBMutableProcessAppNapState|0x12d02d910 enabled:Y active:Y socket:Y disk:Y priority:Y cpu:Y timer:Tier4>
default	13:49:35.366906+0300	Alfred	SetFrontProcess: asn=0x0-0x5c05c options=1
error	13:49:35.367918+0300	WindowServer	CPS: Denying Alfred the right to be in front because secureTextInput is active and this process doesn't have secure text mode enabled, and this request was not caused by user activity
error	13:49:35.373503+0300	WindowServer	CPS: Denying Alfred the right to be in front because secureTextInput is active and this process doesn't have secure text mode enabled, and this request was not caused by user activity
default	13:49:35.373344+0300	Alfred	SetFrontProcess: asn=0x0-0x5c05c options=1
default	13:50:04.372585+0300	runningboardd	Invalidating assertion 380-372-3707 (target:[app<application.com.runningwithcrayons.Alfred.181527167.181527208(501)>:7832]) from originator [daemon<com.apple.WindowServer(88)>:372]
default	13:50:04.492186+0300	runningboardd	[app<application.com.runningwithcrayons.Alfred.181527167.181527208(501)>:7832] Ignoring jetsam update because this process is not memory-managed
default	13:50:04.492387+0300	runningboardd	Calculated state for app<application.com.runningwithcrayons.Alfred.181527167.181527208(501)>: running-active (role: UserInteractive)
default	13:50:04.492563+0300	runningboardd	[app<application.com.runningwithcrayons.Alfred.181527167.181527208(501)>:7832] Ignoring suspend because this process is not lifecycle managed
default	13:50:04.492748+0300	runningboardd	[app<application.com.runningwithcrayons.Alfred.181527167.181527208(501)>:7832] Ignoring GPU update because this process is not GPU managed
default	13:50:18.776711+0300	Alfred	Starting query at qos 0x19

Edited December 18, 2021 by Com30n

[deanishe]

On 12/2/2021 at 4:07 PM, fonginator said:

However, interestingly, keyboard shortcuts for my various workflows still work

No reason shortcuts should be affected: AFAIK, setting a shortcut is telling the OS "call me if this shortcut is pressed". The app doesn't need to watch your keystrokes itself.

 

Snippets are a different matter: Alfred needs to be able to monitor your keypresses to recognise snippet keywords.

[fonginator]

2 hours ago, deanishe said:

No reason shortcuts should be affected: AFAIK, setting a shortcut is telling the OS "call me if this shortcut is pressed". The app doesn't need to watch your keystrokes itself.

 

Snippets are a different matter: Alfred needs to be able to monitor your keypresses to recognise snippet keywords.

How is listening for the activation keystroke different from listening for a keyboard shortcut I’ve set for a specific workflow? Alfred has to monitor keystrokes either way.

[Andrew]

@fonginator the difference is exactly as @deanishe describes.

 

For hotkey combos, macOS offers an API where you register a specific combo of keys with modifiers, and macOS will call back to your app when the user presses that exact combo of keys. This API requires the use of modifiers, e.g. ⌘⌥ and shouldn't be affected by macOS Secure Input locking (aside from the Monterey bug which seems to be causing an issue for a small handful of users in this thread). With using this API, Alfred doesn't have to monitor keystrokes for showing Alfred.

 

For text expansion, Alfred uses the accessibility API which feeds keystrokes used to Alfred's snippet handler. When there is a sequential match of keystrokes, Alfred will instigate the text expansion. This allows any keystroke combination or individual keys to be recognised and form part of a snippet.

 

Cheers,

Andrew

[deanishe]

On 12/19/2021 at 3:18 AM, fonginator said:

How is listening for the activation keystroke different from listening for a keyboard shortcut I’ve set for a specific workflow? Alfred has to monitor keystrokes either way.

 

They use the same mechanism, AFAIK. My (not particularly relevant) point was just that hotkeys do not require Alfred to monitor keystrokes. It isn't not working just because Secure Text Entry is turned on.

[vitor]

There is an alternative way to invoke Alfred. Create a Workflow and connect a Hotkey Trigger to a Run Script Action with Language set to /usr/bin/osascript (AppleScript) and Script tell application "Alfred 4" to search. You can download a ready-made Workflow.

If it works, it’s a seamless workaround until the cause is rooted. But even if it doesn’t work, it will still be important information.

[aMoniker]

I'm running into the same issue where Alfred search cannot be invoked via the main hotkey after focusing on most password fields in browsers, browser extensions, and native apps. It's reproducible. Running Monterey 12.1

 

On 12/21/2021 at 5:43 PM, vitor said:

There is an alternative way to invoke Alfred. Create a Workflow and connect a Hotkey Trigger to a Run Script Action with Language set to /usr/bin/osascript (AppleScript) and Script tell application "Alfred 4" to search. You can download a ready-made Workflow.

If it works, it’s a seamless workaround until the cause is rooted. But even if it doesn’t work, it will still be important information.

 

Thanks for this solution - it does invoke search (with a slight lag time) but unfortunately it suffers from the same problem. Alfred search stops working until I run the app again manually, which so far I've been doing via Spotlight.

 

Let me know if I can do anything to help you track down the cause.

[Vero]

5 hours ago, aMoniker said:

Let me know if I can do anything to help you track down the cause.

 

Could you let us know which version of Alfred you're using? Always best to update to the latest pre-release (4.6.2 at this time)

 

Take a look at the Console logs from earlier in this thread and see whether any of these happen on your Mac, and report these back to us so that we can see what macOS has to say.

 

Also, please let us know in as much detail as possible when it happens (what app is in the foreground), what browser plugins you're using, etc. 

[fonginator]

7 hours ago, Vero said:

 

Could you let us know which version of Alfred you're using? Always best to update to the latest pre-release (4.6.2 at this time)

 

Take a look at the Console logs from earlier in this thread and see whether any of these happen on your Mac, and report these back to us so that we can see what macOS has to say.

 

Also, please let us know in as much detail as possible when it happens (what app is in the foreground), what browser plugins you're using, etc. 

 

@Vero I've already posted my steps to reproduce with Microsoft Teams, but here are two easy ways to "disable" Alfred's activation hotkey:

 

1- Launch Terminal.app, enable Secure Keyboard Entry. This alone is enough to disable Alfred's hotkey.

2- Launch Terminal.app, disable Secure Keyboard Entry. Type sudo -s, hit Return. Alfred's hotkey is now disabled as if Secure Keyboard Entry was enabled (it is not).

 

In both cases, Alfred has not crashed. I can restore Alfred's hotkey by bringing up Spotlight (Command-Space) to launch/activate Alfred. Once that's done, Alfred's hotkey works again.

 

I'm using macOS 12.1, Alfred 4.6.2 [1276]. There have been a number of reports like these in this thread with many scenarios to reproduce the problem, and I wonder whether this is even being looked into or if anyone in the dev team has been able to reproduce this. I don't think I've seen this listed as a known issue or something that's being looked into.

[Vero]

4 hours ago, fonginator said:

There have been a number of reports like these in this thread with many scenarios to reproduce the problem, and I wonder whether this is even being looked into or if anyone in the dev team has been able to reproduce this. I don't think I've seen this listed as a known issue or something that's being looked into.

 

@fonginator As this issue is only affecting a tiny proportion of users, we are actively in the process of trying to gather as much information as possible so as to identify the underlying issue, and why it's affecting so few. Every time anyone has provided any more insight, we've done further tests and still can't replicate the behaviour you're seeing. If it was a widespread or reproducible issue, we would have been able to identify and resolve it, or at the very least, raise a bug report with Apple.

 

Right now, I'm using macOS 12.1 and Alfred 4.6.2, and trying both of your Terminal secure entry tests do not prevent Alfred from operating normally in my tests.

 

Take a critical look at what apps or utilities you have installed, and also apps which would have been installed before Monterey which may no longer be compatible but still operating behind the scenes, as these may be ultimately responsible.

 

Have you tried the suggestion earlier in this thread of creating a new vanilla account on your Mac and testing which behaviour you see on this new account? Another user earlier in the thread reported that this fixed the issue - which points to a specific issue with the primary user profile.

[Finerdly]

I also have this issue and am able to reproduce it by simply focusing (putting text cursor into) a password field in safari and then trying to display the Alfred bar with the global hotkey. From then on I can't bring up the Alfred bar anymore, neither via hotkey nor via "Toggle Alfred" in the menu bar.

Easiest way to fix it for me is using Spotlight to launch Alfred again - it's not a relaunch though as Alfred was running the whole time, but that fixes the issue anyway.

 

Then I created a new MacOS user and quickly realized that this issue is not reproducible there at all. So I don't know what to do now. I guess I just hope this gets fixed somehow sometime.. Really annoying issue though 😐

 

Versions and stuff:
MacOS 12.1

Safari 15.2 & Safari Technology Preview Release 137 (Safari 15.4)

Alfred 4.6.2 [1276] with Powerpack
 

• Using "Toggle Alfred" in the menu bar twice actually also works to make the bar appear and work normally again (as pointed out by user superficial)
• I also got "CPS: Denying Alfred the right to be in front because secureTextInput is active and this process doesn't have secure text mode enabled, and this request was not caused by user activity" in Console.app
• Also tried "go into the Accessibility preferences and uncheck anything other than Alfred. Do the same with any browser plugins."

Edited January 15, 2022 by Finerdly
more info on versions etc.

[vitor]

On 1/13/2022 at 4:00 AM, aMoniker said:

Thanks for this solution - it does invoke search (with a slight lag time) but unfortunately it suffers from the same problem. Alfred search stops working until I run the app again manually

The point is that you’d use the Workflow instead of the main shortcut.

 

39 minutes ago, Finerdly said:

I also have this issue and am able to reproduce it by simply focusing (putting text cursor into) a password field in safari and then trying to display the Alfred bar with the global hotkey.

Do you have any extensions or plugins installed (e.g. 1Password)? Which?

 

41 minutes ago, Finerdly said:

Then I created a new MacOS user and quickly realized that this issue is not reproducible there at all.

Which proves the culprit isn’t Alfred but something else on your machine is causing the bug.

 

Does The Workflow above work for you?

[Finerdly]

1 hour ago, vitor said:

Do you have any extensions or plugins installed (e.g. 1Password)? Which?

Yes, 1Password, OTP Auth and SponsorBlock for YouTube. Like I wrote in my last post it's the same behavior when all extensions are disabled.

 

1 hour ago, vitor said:

Which proves the culprit isn’t Alfred but something else on your machine is causing the bug.

I don't see how that proves that Alfred can't be the issue (it only shows it does not happen with Alfred in combination with a clean MacOS user profile. Surely could be that Alfred is not the problem here, but it's still unclear)

 

EDIT: Actually, I'm pretty sure there is an issue with Alfred here - yes you can say this is maybe like an edge case because it only happens for a few users with some specific set of conditions, but in the end if Alfred App is still running (which it is) but even the menu bar item "Toggle Alfred" is not working anymore (which it isn't) this means the Alfred App is in some kind of broken state at this point. Maybe a real edge case issue here - but an Alfred App issue, probably, nonetheless.

Also it's then easily fixed with just "launching" (not really because it is still running!) Alfred App again - so it seems like something gets undone by doing this..

EDIT2: of course it could also be a MacOS bug which then weirdly breaks Alfred App, I guess.

 

1 hour ago, vitor said:

Does The Workflow above work for you?

No, same for me as for user aMoniker, it breaks in exactly the same way when using this workflow to invoke Alfred 

Edited January 15, 2022 by Finerdly

[vitor]

19 minutes ago, Finerdly said:

I don't see how that proves that Alfred can't be the issue

Look at your own post, specifically the Console.app output: Alfred is trying to show but is being stopped. And that is happening because of something you have installed/configured, as evidenced by the fact it doesn’t happen on a fresh account.

 

If you are trying to drive down a road but can’t proceed because there’s a barricade in the way, is it your car’s fault? No, it’s the fault of whoever blocked the road, which is why it’s important to figure out exactly who that is.

 

Which app(s) is causing this to happen and in which circumstances? After finding that and getting a consistent way to reproduce, perhaps Alfred can implement a workaround or we can file a bug report with the source of the problem.