Bug: Prompt for User Input: `OK` button is not blue

It's a good thought and thanks (you too @JMichaelTX) !

But I've tried that. The dialog is definitely in its front/active state.

I wouldn't be surprised if the cause is related to this though. As in: The buttons think (for reasons related to their parent window's state) that they should present as being in their in the background state.

The KM Prompt windows below to the KM Engine -- so they don't really have a "parent window". But if you mean the app that is frontmost when you trigger the macro with the Prompt, then that might affect it if you in some way activated the app AFTER displaying the prompt.

For example, if I display the Prompt, then trigger LaunchBar, its prompt has focus, and the KM Prompt then does NOT color its buttons:

By "parent window" I was referring to the Keyboard Maestro popup window itself. The place where the OK button lives within.

(I don't have an evidence. It was just a deduction on my part that points to a relatively likely cause. But I could be totally off.)

Of course.

Since it affects Alerts as well, I'd guess it is a system or a memory corruption issue. Try the usual fixes - restarting Keyboard Maestro Engine or restarting your system.

After that Safe Boot would be the next thing to try.

Tried both of those.

Hum... That would certain clear a few things out.

What do you think about the fact that it seems to be only effecting the Default button in Keyboard Maestro windows but no others?

No idea. The buttons are clearly default buttons or they would not response to Return. So it is a system display issue.

You don't happen to have XtraFinder installed? That can mess up UI stuff.

Other than that, I would look at some sort of extension - it's really not up to Keyboard Maestro to draw the buttons, the system handles that.

No (good thought).

As I mentioned above, I have Default Folder installed, but quitting that didn't help.

From what I remember (and maybe I'm wrong), nothing on the system has changed in a while. The newest update was Keyboard Maestro, to 9.0.6. Which is why I thought maybe something changed there and as interacting in a funny way with 10.11.6.

I have a backup of 9.0.5 (and earlier), but was hesitant to try them because I didn't want to corrupt the preferences.

Would it be safe (and worth it) to swap out these minor versions of "Keyboard Maestro.app"

Running the same Mac OS (10.11.6) and Keyboard Maestro (9.0.6) versions, I see the same behavior as described by @ar-km.

A safe way to do this without risking 9.0.6 or later is to

  1. while keeping 9.0.6 around, install 9.0.5 (or earlier) but do not launch it;
  2. create a new user account and log in to that user account;
  3. open 9.0.5 from within the new user account to test its button-appearance behavior.

When testing is complete, log back in to your original user account to delete the user account created for testing. All that will remain of KM 9.0.5 is the app shown in the Finder and that can be safely moved to the Trash. KM 9.0.6 and any of its associated files should remain perfectly intact.

That's a really good idea... and thorough.

iu

I was going to just copy all of the 9.0.6 files in:

  • ~/Library/Application Support/Keyboard Maestro
  • ~/Library/Preferences/Keyboard Maestro*
  • etc.

Swap out the version for 9.0.5, test, and then move the 9.0.6 versions back in place.

But I like your idea much better.

Before I test that and since you too are on 10.11.6:

  • Have you tried this?
  • If it's still there in 9.0.5, what about 9.0.4 ?

Thanks!

Just tried it now, upon reading your post and thinking the prior versions might be available from the Keyboard Maestro site (they are). Both 9.0.4 and 9.0.5 showed the OK button highlighted.

Ahh! That's great. Thanks.

@peternlewis Is there anything else that might help you track this down?

It appears to be a bug in recent versions of Xcode, when it compiles the interface files for those windows, it has made some change that results in the failure to display correctly in older versions of OSX.

I have reported it to Apple, but there isn't anything I can do directly, since reverting to using older versions of Xcode is not really practical.

2 Likes

Cool.
That's great that you were able to track it down.

Are you able to test/reproduce in 10.11.6, or otherwise verify when it's broken and then (hopefully) fixed?

In any case, I'll report back here if I see it change in a future release.

Thanks!

Yes, I have a test Mac that runs 11.6, which I always test (just a cursory test) every release on to ensure there is no obvious failings.

I'm afraid I wont be holding my breath on Apple fixing this, but you never can tell, they have fixed a few bugs I've reported over the years.

:+1:

Understood. Same.

Can you post the Radar/Feedback Assistant number here, in case anyone else runs into this and wants to report it too?

Thanks!

FB8703845 “Recent versions of Xcode compile .xib to .nib result in non-highlighted default buttons in 10.11”

Thank you!

“10.11”. Are Apple even likely to fix a problem that affects such an ancient release?

Since Xcode supports setting the Deployment target for the interface, and it is configured for 10.11, which it claims to still support, yes they might. It really depends on why it is failing and what it is doing wrong - it is quite possible the bug could affect other things, and until they know what it is doing and why, they won't know whether there are other potential consequences. And once they do, it may be an easy fix. Or not. Or they may not care. Who knows?

1 Like