Alfred doesn't show the text cursor in macOS Sonoma if the redesigned text cursor is disabled

[Hedgehog]

When using the plist tweak to disable the caps lock indicator and to revert to the old language switcher in macOS Sonoma, Alfred will not show the text cursor.

 

The plist setting is:

sudo defaults write /Library/Preferences/FeatureFlags/Domain/UIKit.plist redesigned_text_cursor -dict-add Enabled -bool NO

as described here: https://stackoverflow.com/a/77296786

 

I am running Alfred 5.1.4 [2195] and macOS Sonoma 14.1 (23B74).

[Andrew]

@Hedgehog  This will be a bug in macOS as Alfred just uses a standard macOS text field. Alfred does set the cursor colour to match the theme text colour, but I can't imagine this would change the behaviour as it's working in a default Sonoma configuration.

 

I've taken a look and can't find any Apple documentation for redesigned_text_cursor, do you have a source? Apple are likely to reject any bug report if this is an undocumented setting.

 

Some things you could try in Alfred is setting the focus mode in the Appearance > Options to Compatibility mode, which will make Alfred operate more like a normal macOS window instead of a floating panel. Also, try a different theme, perhaps Alfred Modern or Alfred Modern Dark, as these both use a native visual effect view background.

 

Cheers,

Andrew

[luckman212]

Just came to report the same thing! So far I've only noticed the "mysterious missing cursor" in Alfred's windows. Interestingly, it seems to affect ALL text fields throughout the app, including the Preferences and Workflow text search fields. 

 

I tried changing Focus Mode to Compatibility, and it DID fix it... ONCE. The first time I invoked Alfred after making that switch, the blinking cursor reappeared. But, after dismissing him and then re-invoking, the cursor was gone again. Changing back to Standard, and then back to Compatibility made the cursor reappear exactly once. Very strange stuff.

 

Here are some little clips that show it

 

 

 

[Vero]

@luckman212 Are you using the same hack described in the first post? And which version of macOS and Alfred are you using?

[luckman212]

@Vero Sorry, yes! I'm using that same undocumented preference setting, and yes I'm on Sonoma 14.1 (23B74) + Alfred 5.1.4.2195, same as @Hedgehog

 

Also, deleting /Library/Preferences/FeatureFlags/Domain/UIKit.plist and logging out and back in isn't enough. A full reboot is required. I guess this is not a user-level thing.

Edited October 26 by luckman212

[Hedgehog]

@Andrew My source for the tweak is the Stack Overflow post I linked - it indeed does not appear to be an officially documented macOS feature, but it does revert to pre-Sonoma behavior and the only affected application appears to be Alfred.

 

For reference, changing the theme did not help - as @luckman212 pointed out, even other parts of Alfred are affected by this.

[Andrew]

A theory as to why you're only seeing Alfred affected is that we support a broad range of macOS Versions (back to 10.14 for Alfred 5), and as such, Alfred is built against this macOS SDK. We have seen in the past that different macOS targets can give different behaviours (with sizing and layout), so it's quite conceivable that this tweak only fixes the cursor for apps built against a newer SDK than what Alfred is targeting. This is further compounded by two observations:

1. Apple have convoluted "automatic" switching support for their TextKit 1 and TextKit 2 APIs (TextKit 2 is only supported on macOS 13+ from the docs). Alfred will be using TextKit 1 due to broad OS support, which may not know about redesigned_text_cursor.
2. The plist hack being used is on something named UIKit, which is an iOS specific toolkit vs the macOS equivalent AppKit. I understand there is convergence between macOS and iOS, which is being implemented over time in a black box manner, but it's far from finished. Undocumented tweaks which have only been found by reverse engineering (debugging) a binary will not be intended for use by end users as this feature may just be unfinished or for development / testing purposes.

There isn't an easy solution to this, except in saying that the text rendering system is extremely complicated, and it's highly unlikely Apple will provide us with any support on how to work around an issue caused by using an undocumented tweak.

 

Having said that, if Apple do make this a checkbox in the preferences, and make reverting the text cursor an official macOS Sonoma feature, I would imagine it will automatically work in Alfred. If not, this is the point at which it will be easy to raise this as a bug, and get DTS level support on the issue.

 

We will monitor this situation as far as Alfred is concerned, but for now, all I can recommend is that you shouldn't really be using the redesigned_text_cursor tweak until Apple make this a public option.

[luckman212]

Thanks @Andrew for the explanation. I've rolled back the tweak on my systems for now. Hope Apple does something better in the future. The new caps lock thing is hideous.

[Hedgehog]

Really wish I could keep using this tweak, as I've noticed that the new language switcher behaves differently when cycling between more than two keyboard layouts - it will cycle between the last two on the list rather than the last two used ones like on previous macOS versions.

 

For reference, this is the command to remove the tweak:

sudo defaults delete /Library/Preferences/FeatureFlags/Domain/UIKit.plist redesigned_text_cursor

You must reboot after running it, same as adding it.

Edited October 26 by Hedgehog

[Hedgehog]

I wrote a small Hammerspoon (https://hammerspoon.org) script which will work around this issue by drawing its own text cursor at the right position when Alfred or Alfred Preferences are focused. This is done by getting the cursor position using Apple's accessibility APIs then leveraging Hammerspoon's own abilities to draw the text cursor at the right spot.

 

-- Alfred redesigned_text_cursor fix
--
-- Save this in a file named something like `alfred_cursor_fix.lua` in the Hammerspoon config folder (`~/.hammerspoon`),
-- then import it from your Hammerspoon `init.lua` file:
--
-- ```lua
-- alfred_cursor_fix = dofile('alfred_cursor_fix.lua')
-- ```

local obj = {}

obj.canvas = hs.canvas.new({ x = 10, y = 10, w = 10, h = 10 })
obj.canvas:appendElements({
    {
        type = "rectangle",
        action = "fill",
        frame = { x = 0, y = 0, w = 10000, h = 10000 },

        -- text cursor color definition
        fillColor = { red = 0.5, green = 0.5, blue = 0.5, alpha = 1 },
    }
})
obj.caret_blink_timer = hs.timer.doEvery(1 / 2, function()
    local rect = obj.canvas[1]
    if rect.fillColor.alpha == 0 then
        rect.fillColor.alpha = 1
    else
        rect.fillColor.alpha = 0
    end
end)

obj.timer = hs.timer.new(1 / 120, function()
    local el = hs.axuielement.systemWideElement().AXFocusedUIElement
    if el == nil then
        obj.canvas:hide()
        return
    end

    local range = el.AXSelectedTextRange
    if range == nil or range.length > 0 then
        obj.canvas:hide()
        return
    end

    local loc = el:parameterizedAttributeValue('AXBoundsForRange',
        { length = 1, location = math.max(0, range.location - 1) })
    if loc == nil then
        obj.canvas:hide()
        return
    end

    local x = loc.x
    if range.location > 0 then
        x = x + loc.w
    end
    local old_frame = obj.canvas:frame()
    local new_frame = { x = x, y = loc.y, h = loc.h, w = 2 }
    for k, _ in pairs(new_frame) do
        if math.floor(old_frame[k]) ~= math.floor(new_frame[k]) then
            obj.canvas:frame(new_frame)
            obj.canvas:show()

            -- text cursors don't seem to blink while typing
            obj.canvas[1].fillColor.alpha = 1
            break
        end
    end
end)

function obj:hide()
    obj.timer:stop()
    obj.canvas:hide()
end

function obj:show()
    obj.timer:start()
end

-- window filter didn't seem to pick up the alfred search window so polling here instead
obj.window_timer = hs.timer.doEvery(1 / 10, function()
    local el = hs.axuielement.systemWideElement().AXFocusedUIElement
    if el == nil then
        obj:hide()
        return
    end

    local app = hs.application.applicationForPID(el:pid())
    if app == nil then
        obj:hide()
        return
    end

    local app_name = app:name()
    if app_name == "Alfred" or app_name == "Alfred Preferences" then
        obj:show()
    else
        obj:hide()
    end
end)

return obj

 

Edited October 29 by Hedgehog

[smlngst]

FYI:  Stephan Casas, who was the person who originally discovered the flag to disable the new style text cursor, helped me to find a flag that will disable new input source switcher popup without the unwanted side effect of the text cursor not showing up in some circumstances.

 

This won't disable the CapsLock indicator, however, there might end up being another flag for that (see the discussion in the link below).

 

To disable just the new style language/input switcher:

 

First, if you had used the previous flag to disable the new style text cursor completely, you should probably delete it as described above using:

 

sudo defaults delete /Library/Preferences/FeatureFlags/Domain/UIKit.plist redesigned_text_cursor

 

You'll probably need to restart your system to re-enable the new style text cursor.

 

After that, disabling the inline input switcher pop up is as simple as:

 

defaults write kCFPreferencesAnyApplication TSMLanguageIndicatorEnabled 0

 

That makes the system start using the old center screen HUD style input method switcher immediately, without needing to restart your system. 

 

Any open applications will still show a popup when the input method is changed. However, once an app is restarted, it will no longer show an indicator when it's changed.

 

That's more than enough for me. Hopefully Apple won't change it. :)

 

Again, this won't disable the CapsLock indicator.

 

See here for further discussion: https://gist.github.com/stephancasas/236f543b0f9f6509f5fe5878de01e38a?permalink_comment_id=4748936#gistcomment-4748936 

 

 

[luckman212]

I sincerely hope someone at Apple is paying attention to these threads. Whoever's in charge (I'm guessing literally nobody...) of making these bad decisions to mess with something as fundamental as text input at this stage of macOS' maturity is really out of touch.

[smlngst]

I've been trying to encourage people like me who dislike the changes to leave feedback here: https://www.apple.com/feedback/macos.html. It still might not get enough traction, but has more likelihood of being seen.

[luckman212]

@smlngst Good idea. Feedback submitted!