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

[fonginator]

FWIW, I also see these log messages immediately after the activation problem:

 

error    12:43:11.956984-0500    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    12:43:11.960613-0500    Alfred    Item (<private>) was removed because there is not enough space. minWidth=389.000000

 

Running Alfred 4.6.2 [1276]

 

I tested with a new user account and did not immediately reproduce this problem; however, this seems to occur some time after my Mac has been running so I cannot say conclusively whether this is an issue related to other apps or whether something happens over time that would also affect my new user (test) account.

 

[deanishe]

Does anyone even know what this "CPS" is?

 

I've found some similar reports for other apps, but no solutions

 

The other affected applications also seem to use non-focusing windows.

 

Has anyone tried setting Alfred's Focusing to "Compatibility Mode" in Alfred Preferences > Appearance > Options?

Edited January 16, 2022 by deanishe
Remove stupid "not"

[Finerdly]

1 hour ago, deanishe said:

Has anyone tried setting Alfred's Focusing to "Compatibility Mode" in Alfred Preferences > Appearance > Options?

EDIT: For everyone looking for a solution, this worked for me:

Turns out I had this Alfred Appearance Compatibility Mode enabled - after switching to "Standard Mode" the issue disappeared for me! Thanks a ton @deanishe !

 

I can't remember ever enabling this, as far as I know I was never aware of that feature - could it be this was enabled by default when using Alfred since some very old version? I suppose "Standard Mode" is the current default, right?

 

EDIT: Seems like this Compatibility Mode was introduced in 2015: https://www.alfredapp.com/blog/releases/alfred-2-7-3-pre-release-to-improve-window-focus-reliability/
 

Quote

As a side-effect of the window focus changes in 2.7.2, an even smaller number of users who use Java applications (e.g. IntelliJ) were encountering odd Java-related behaviour when trying to paste from Alfred's clipboard history - a Java caching issue which affects all OS X clipboard managers. To alleviate this, we've added a Compatibility mode, allowing Alfred to act like an app (as opposed to a non-activating panel) and take focus when in use.

 

This may also help if you use keyboard remapping tools, such as Karabiner. However, the Karabiner developer has already updated the latest beta to support the new activating style of Alfred 2.7.2.

Well I guess I enabled it 6 years ago then.. 🤔

 

@Vero So there seems to be an issue with Monterey and Alfred's Appearance Compatibility Mode?

Edited January 15, 2022 by Finerdly

[fonginator]

Yes! @deanishe's suggestion fixes the problem for me. I never changed the Focusing mode setting (been running Alfred since its early days).

[deanishe]

I'm glad Alfred's working for you now.

 

I find it a bit worrisome that turning compatibility mode on worked for one of you, while turning it off worked for the other.

[Finerdly]

44 minutes ago, deanishe said:

I find it a bit worrisome that turning compatibility mode on worked for one of you, while turning it off worked for the other.

I see what you mean, this would be very strange - but I actually tested it on a clean MacOS user and it was easily reproducible by just switching to Alfred Appearance Compatibility Mode, focusing a password field on some website in Safari and then using the global Alfred Hotkey to make it break in the same way I had it break all the time on my normal MacOS user.

 

So I think @fonginator's post was just unintentionally a little bit misleading. Maybe @fonginator can clear this up for us

Edited January 16, 2022 by Finerdly

[Andrew]

Excellent!! Thanks for all the sleuthing and finding the cause and an easy fix.

 

The default setting is "Standard Mode" with no reason to change from this anymore, which I guess is why we are only seeing this in a tiny proportion of users. @fonginator I assume you were in Compatibility Mode and switching back to Standard fixed it for you? (you may have played with this setting long in the past and forgotten).

 

Using the CPS console clue, I tried double clicking the Alfred 4.app icon, and this is enough to get things working normally again (this is a user action in the eyes of macOS, and Alfred will show the window when you double click). From this, I see that simply opening Alfred with "open /Applications/Alfred\ 4.app" in Terminal is enough to get the macOS Window Server to believe there was a user action.

 

If you absolutely need to use Compatibility Mode (unlikely in modern macOS which fixes the window focusing oddities which led to needing the Compatibility mode), then creating a workflow with a Hotkey Trigger (with trigger mode set to Pass through modifier keys so that it's instant), Action set to Pass through to workflow. Connect this to an Open File and drag Alfred 4.app in. With this workflow, it looks like macOS still won't allow Alfred to show over a secure entry, but will allow to show normally after the secure entry is turned off again.

 

The fix for anybody who is experiencing this is to set the Appearance > Options  > Focusing to Standard Mode.

 

Cheers,

Andrew

[fonginator]

17 hours ago, Finerdly said:

I see what you mean, this would be very strange - but I actually tested it on a clean MacOS user and it was easily reproducible by just switching to Alfred Appearance Compatibility Mode, focusing a password field on some website in Safari and then using the global Alfred Hotkey to make it break in the same way I had it break all the time on my normal MacOS user.

 

So I think @fonginator's post was just unintentionally a little bit misleading. Maybe @fonginator can clear this up for us

 

Yes! I actually re-tested this after the resolution and was able to reproduce this on demand after toggling said setting… and not after some period of use.

[fonginator]

6 hours ago, Andrew said:

The default setting is "Standard Mode" with no reason to change from this anymore, which I guess is why we are only seeing this in a tiny proportion of users. @fonginator I assume you were in Compatibility Mode and switching back to Standard fixed it for you? (you may have played with this setting long in the past and forgotten).

 

This setting is so buried I don't know why I would've played with it… but I registered for the Powerpack way back in 2010 so I can't vouch for every setting I've played with in the intervening years. 😅

 

6 hours ago, Andrew said:

Using the CPS console clue, I tried double clicking the Alfred 4.app icon, and this is enough to get things working normally again (this is a user action in the eyes of macOS, and Alfred will show the window when you double click). From this, I see that simply opening Alfred with "open /Applications/Alfred\ 4.app" in Terminal is enough to get the macOS Window Server to believe there was a user action.

 

I suppose this explains why activating Alfred with Spotlight "re-activated" Alfred's hotkey combination when I experienced this issue. In any event, I wonder how many other people may be having this problem but have not bothered reporting it. Maybe there should be some sort of one-time warning or some obvious mention if someone has Compatibility Mode enabled?

[Alexandre Viau]

I am also getting this issue. Alfred stops responding to its hotkey after I click on a password field (I have 1password). Clicking the Alfred app seems to fix the issue until I click on a password field again.

 

On 1/16/2022 at 6:56 AM, Andrew said:

The default setting is "Standard Mode" with no reason to change from this anymore,

 

Turning off compatibility mode fixes the issue. However, my key bindings depend on compatibility mode (otherwise karabiner can't tell that Alfred is on the foreground). Compatibility mode is one of the top features that made me buy Alfred.

 

Would it be possible to fix this without having to turn off compatibility mode?

 

Note to devs: I am available to help debugging this, but looking at the thread I think that the repro steps have now been correctly identified.

Edited January 31, 2022 by Alexandre Viau

[Andrew]

@Alexandre Viau you can work around this macOS issue as I described earlier:

 

On 1/16/2022 at 11:56 AM, Andrew said:

If you absolutely need to use Compatibility Mode (unlikely in modern macOS which fixes the window focusing oddities which led to needing the Compatibility mode), then creating a workflow with a Hotkey Trigger (with trigger mode set to Pass through modifier keys so that it's instant), Action set to Pass through to workflow. Connect this to an Open File and drag Alfred 4.app in. With this workflow, it looks like macOS still won't allow Alfred to show over a secure entry, but will allow to show normally after the secure entry is turned off again.

 

Essentially, this makes macOS believe it's a user based action and allows Alfred to show.

 

Set your default hotkey to something obscure, and set your preferred hotkey in the workflow.

[Alexandre Viau]

This fix would work if I only wanted to trigger Alfred's main prompt but it can't be used to launch other hotkey-triggered workflows.

 

 

(great idea by the way haha!)

Edited January 31, 2022 by Alexandre Viau

[godbout]

On 1/16/2022 at 7:56 PM, Andrew said:

If you absolutely need to use Compatibility Mode (unlikely in modern macOS which fixes the window focusing oddities which led to needing the Compatibility mode), then creating a workflow with a Hotkey Trigger (with trigger mode set to Pass through modifier keys so that it's instant), Action set to Pass through to workflow. Connect this to an Open File and drag Alfred 4.app in. With this workflow, it looks like macOS still won't allow Alfred to show over a secure entry, but will allow to show normally after the secure entry is turned off again.

 

i'm coming back here because on top of the issue where Alfred showing up on the wrong screen sometimes (we talked privately about that one), i had the current issue with the password fields. for me the reason to use Compatibility though is that the Standard more almost never registers my first key if i type fast (also discussed privately; but the idea that an other program was stealing my Alfred hotkey is not convincing). so, glad to see there's another way. thanks.

[Com30n]

On 1/15/2022 at 8:59 PM, deanishe said:

Does anyone even know what this "CPS" is?

 

I've found some similar reports for other apps, but no solutions

 

The other affected applications also seem to use non-focusing windows.

 

Has anyone tried setting Alfred's Focusing to "Compatibility Mode" in Alfred Preferences > Appearance > Options?

Finally! Thanks a lot!

I changed "Compatibility Mode" to "Standart Mode", and it is working!

The problems when the alfred search window doesn't work with "password" fields in 1Password and Lastpass are gone

[Andrew]

I now have a workaround for this Monterey bug in 4.6.4 b1291 pre-release.

 

If you need to use Alfred's focus compatibility mode, could you please update to this pre-release and let me know how you get on.

 

NOTE: macOS will still prevent Alfred (in focus Compatibility Mode) from showing over a secure entry field, but once you move the focus away from the secure entry, Alfred will work again as normal.