Invisible text in autocomplete dropdowns

slifty

This started happening last year and I just ignored it, but I'm reaching a breaking point…

I'm running MacOS 14.3.1 and using the latest version of quicken.

Most of the text content of autocomplete drop down UX is rendered invisibly (or as white with a white background possibly). For example, if I click into a Payee this is what I see:

If I hover over the rows of the drop down the background changes to reflect the highlight and I can see the text:

Does anybody else have this problem? Any suggestions on what I can do?

I've tried reinstalling, deleting plists, creating a fresh file from scratch, and nothing has worked!

jacobs

I've never seen that before either. Is this a test file? What you showed here seems to show that you have no Payees with an "a" in them other than "a" and "asdf".

I created a new file and created two transactions, for Payee "a" and "asdf", saving QuickFill rules for each one with the category Uncategorized. When I start entering another transaction by typing "a", here's what I see:

Notice that the second and fourth items in this list are in exactly the same place as in your list, but the first and third are whited out in yours. The first of the three balance adjustment transactions in mine is visible in yours, but the second and third aren't. So everything is in the right place in yours, but for some reason some of the entries are whited out.

One thing you might try is switching to dark mode to see if that reveals anything other than the empty places text should be:

I agree with where @RickO was going in his reply. What appears on the screen in registers is mostly handled by macOS, and it seems something is unsettled.

One quick thing you can try is switching your macOS Appearance to dark mode, and then back to light mode to see if that changes anything.

I would normally say to restart the computer but if this has been happening to you since last year, I'm sure you've restarted at least once somewhere along the way.

Rick's suggestion of starting up in Safe Mode is a good way to isolate any user-installed system modifications to see if it resolves the issue or not. (How to do this depends if you have an Intel Mac or a M1/M2/M3 Mac; see here for details.)

Another possible test is to create a new macOS User account. Log into that Users, launch Quicken, and create a new test file. Does it behave the same or behave correctly?

These tests should hopefully start pointing a finger towards a culprit.

slifty

Thank you all these are great suggestions. @jacobs yes indeed this is a test file (I figured it would be simpler to start from a clean slate) and there is only ONE payee "asdf" just as you re-created in your example.

Some updates on my end after exploring based on y'all's advice.

1: Switching to dark mode does fix the issue (and switching back to light brings the issue back):

2: Restarting into safe mode did not do the trick, unfortunately:

I'll try making a new user now!

slifty

Another update — creating a new user did solve the problem. The new user doesn't have anything wrong. Fascinating!

I'm now scouring my dotfiles / provisioning script to see if anything there might conflict… (I can't link directly but it's at https://github.com/slifty/dotfiles/blob/main/macos/install.sh)

dan.greenberg.ct

I'm curious if you have some weird font that you're using that Quicken doesn't like. Have you tried changing Register Text and Row Settings to the default or other options to see if it fixes it? I've tried several combinations of light and dark modes with different register heights and fonts and can't recreate this, luckily :)

jacobs

@dan.greenberg.ct That's a good idea I hadn't thought of, but I don't think it comes into play here because this is a drop-down menu; the Register Text and Row Settings should only be affecting the text and row spacing in a register, not in a menu.

@slifty I'm still puzzled, but I'm glad we're zeroing in on… something. It's interesting that it works okay in dark mode; if it was a bad font, I would think the same problem would occur in light and dark mode. It's actually good that switching to Safe Mode didn't solve it, because that indicates it's not some weird third-party system modifier at work. And it's good that it works correctly in a new User account, as that seems to prove it's not a problem with the Quicken application or your macOS.

I would look in your Users/your account/Library/Preferences folder for the com.quicken.Quicken.plist file — the Quicken preferences file. Quit Quicken, then drag this file to your desktop, then relaunch Quicken. That will force Quicken to generate a new .plist file from scratch. Does that solve the font problem? If so, continue wit the newly-created .plist file; you'll need to re-set/configue a number of settings in Quicken, but you'll be over the hump. If it doesn't work, you can drag the original .plist file from your Desktop back into the Preferences folder to replace the newer one it created… and be back to Square One.

slifty

@jacobs alas — wiping the plists doesn't fix the problem (I tried again for good measure, but no luck).

@dan.greenberg.ct good thought and I did try messing with the fonts with no success.

Here's a log from my console from the time of clicking into the payee / opening the context menu, though I'm not seeing anything particularly useful here:

default	21:15:27.000905-0500	Quicken	[0x600001ef81e0] activating connection: mach=false listener=false peer=false name=com.apple.TextInputUI.xpc.CursorUIViewService
default	21:15:27.001444-0500	Quicken	[0x600001ef81e0] invalidated after the last release of the connection object
default	21:15:27.022094-0500	Quicken	[0x121a05670] activating connection: mach=false listener=false peer=false name=(anonymous)
default	21:15:27.022145-0500	Quicken	[0x142f10aa0] activating connection: mach=false listener=false peer=false name=(anonymous)
default	21:15:27.026160-0500	Quicken	parent MainWindow 0x142ee8940 (5f3) remove FauxMenuWindow 0x142e833c0 (63b) from group
default	21:15:27.027286-0500	Quicken	parent MainWindow 0x142ee8940 (5f3) add FauxMenuWindow 0x142e833c0 (63b) to group
default	21:15:27.027528-0500	Quicken	order window: 63b op: 1 relative: 5f3 related: 0
default	21:15:27.039869-0500	Quicken	-[TUINSCursorUIController activate:]_block_invoke: Create CursorUIViewService: TUINSRemoteViewController
default	21:15:27.039963-0500	Quicken	[0x1441c1e20] invalidated on xpc_connection_cancel()
default	21:15:27.039983-0500	Quicken	[0x121a6c070] invalidated on xpc_connection_cancel()

slifty

Welp, I think I solved it.

Part of my provisioning script for setting up my machine involves setting a custom highlight color using the following command:

defaults write NSGlobalDomain AppleHighlightColor -string "0.064700 0.568600 0.996500"

If I go into the system preferences appearance panel and manually set a highlight color it fixes the behavior in Quicken (even if I set it to a "custom" color).

I was curious what changed in the actual NSGlobalDomain plist when setting via UX instead of via command line, and so I inspected the plist via plutil. When set via the UX it shows that the correct value for an AppleHighlightColor is "AppleHighlightColor" => "0.064700 0.568600 0.996500 Other" ← with "Other" at the end of the string.

So… adding "Other" to the string, including via that command line command fixes it, OR manually selecting a highlight color via the system window fixes it.

It's not clear to me why this value would break the font color in a context menu (or in Quicken) but that's definitely the impact and I suppose it makes sense that some OS level function related to UI rendering is expecting a specific form for its settings, and it could behave unpredictably if that form is not met.

If anybody else is feeling bold and interested in reproducing to see if manually setting this value is the actual cause, I'd be curious!

Thank you so much everybody for helping hone in on the problem.

Broken:

Working:

slifty

(Sorry if this is a double post; it looks like my conclusion got deleted somehow!)

I don't understand why this is the problem, but it appears to be.

My provisioning script sets a custom highlight color: defaults write NSGlobalDomain AppleHighlightColor -string "0.064700 0.568600 0.996500

If I manually set a highlight color using the system preferences UI, everything works. Upon inspection of the plist it appears the UI inserts "Other" to the end of the RGB string: 0.064700 0.568600 0.996500 Other.

Ultimately having the word "Other" on the end of the AppleHighlightColor setting fixes the problem. Wild.

Broken:

Fixed:

Note for anybody who is curious and wants to try this on your own, you have to restart quicken in order for the CLI-based plist updates to affect the rendering. Thank you so much to everybody for helping me hone in on this!

dan.greenberg.ct

Glad you figured this out!