Virtual Sanity

Vertically Off-Center Components in NSSearchToolbarItem in macOS 27 Developer Beta 5

2026-08-12T07:29:48-04:00

In macOS 27 developer beta 5, search fields in toolbars (NSSearchToolbarItem instances) have their placeholder text, search strings, and magnifying glass icons vertically off-center. I reported this as FB24286690.

You can see this in the Feedback Assistant app. The “Search” placeholder text, the magnifying glass, and the search string are all closer to the top of the toolbar item than the bottom.

I have a sample project demonstrating this.

To reproduce this:

Open the sample project.
Observe that the sample project is a simple AppKit app that creates a window with a toolbar. The toolbar has an NSSearchToolbarItem.
Run the app.

Expected results: The app presents a window with a toolbar. The toolbar has a search field. Alignment of all elements looks good.

Actual results: The magnifying glass, “Search” placeholder text, and any entered search string are much closer to the top of the text field than the bottom.

It looks like the placeholder text is 11 points from the top border of the toolbar item, and 16 points from the bottom border.

You can also see the effect in the toolbar customization palette. Choose “Customize Toolbar…” from the View menu. The search toolbar item elements are also closer to the top of the toolbar item than the bottom in that palette.

This is a screenshot of my sample app:

This is a screenshot of the toolbar customization palette in the sample app:

This is a screenshot of the top of the main window of the Feedback Assistant app:

NSTrackingSeparatorToolbarItem causes white bar over top of content in macOS 27 developer beta 5

2026-08-11T09:24:11-04:00

macOS 27 developer beta 5 (26A5406e) introduces a bug that causes a white bar to appear over window content if the window’s toolbar has an NSTrackingSeparatorToolbarItem. I filed FB24266969 with Apple describing this.

I have a sample project demonstrating this. This is a screenshot of the result:

To reproduce the issue:

Open the attached sample project.
Observe that the app presents a simple window with a 3-pane split view and a toolbar, and that there is a NSTrackingSeparatorToolbarItem tracking the separator between the second split view pane and the third split view pane.
Run the app on a Mac running macOS 27 developer beta 5.

Expected results: The window should appear with a toolbar and the three panes.

Actual results: The window appears, but there is a white bar covering the top of the content. That white bar is roughly the height of the toolbar, but it is below the toolbar.

Interestingly, I described a somewhat similar issue almost a month ago with developer beta 3. That prior issue only became visible after invoking full screen mode. It was fixed in developer beta 4. This new issue happens right away when the window appears.

NSTrackingSeparatorToolbarItem causes problems when putting a window in full screen on Golden Gate (macOS 27)

2026-07-18T15:30:41-04:00

Update July 20: Developer beta 4 seems to fix this.

NSTrackingSeparatorToolbarItem adds a white band over the top of the leading split view panes when in full screen mode on macOS 27. That white band appears to have the height of the toolbar.

I have a sample project that demonstrates the issue. To reproduce it:

Download and open the sample project. Observe that the main window contains a simple three pane split view. Also observe that the window it creates has a toolbar with an NSTrackingSeparatorToolbarItem. The NSTrackingSeparatorToolbarItem tracks the divider between the second pane and the third pane.
Run the attached sample project on a Mac running Golden Gate (macOS 27).
Click the green traffic light button in the upper left corner of the window.

Expected results: I expected a smooth animation. I expected all three panes to be completely visible when in full screen.

Actual results: The animation looks janky near the top of the screen. When the animation is complete, a white band covers the top of the first two panes.

The symptoms change if you repeat entering and exiting full screen mode during the same session.

This is a video of my following these steps:

I filed this as FB23827858 and am hoping it gets attention.

Update July 20: Developer beta 4 seems to fix this.

Bug Involving Keyboard Shortcuts for Menu Items That Have No Modifier Keys on macOS 26.5

2026-05-12T13:28:22-04:00

I am seeing a bug that affects keyboard shortcuts that have no modifiers and are attached to menu items. For example, the bug would affect the keyboard shortcut J on a menu item, but not the keyboard shortcut ⌘J.

I believe this bug was introduced in macOS 26.5. It is also present in the first developer beta of macOS 27.

I filed this as FB22762541, and am writing this to let others know about it.

I do not have a macOS 26.4 environment to test against, but based on customer input I believe this is a new bug in macOS 26.5.

The Bug

When a menu item is invoked with a keyboard shortcut that has no modifiers and its validateMenuItem(_:) method returns false, the system beeps and refuses to perform the operation. This is expected.

But then even after validateMenuItem(_:) is returning true again, the app will continue refusing to perform that keyboard shortcut until the app is quit and relaunched. It will also do the same with all other keyboard shortcuts that have no modifiers and are attached to menu items.

In addition, if a key is pressed for which there first responder to handle it, the system gets into the same state. The next valid key command without a modifier might get processed, but ones after that will not.

Sample App

To demonstrate this, I wrote a sample project.

Its app shows a counter. The File menu has these menu items:

Increment Counter (keyboard shortcut: ⌘J)
Increment Counter (keyboard shortcut: J)
Decrement Counter (keyboard shortcut: ⌘K)
Decrement Counter (keyboard shortcut: K)

The app also has an Enable Menu Items checkbox. When checked, validateMenuItem(_:) returns true for the four menu items above. When unchecked, it returns false.

To see the issue:

Run the sample app.
Take note of the Increment/Decrement Counter menu items in the File menu.
Increment the counter with the ⌘J and J keyboard shortcuts. Decrement the counter with the ⌘K and K keyboard shortcuts. Observe that all four keyboard shortcuts work as one would expect.
Uncheck the Enable Menu Items checkbox.
Open the File menu, and observe that the four menu items are disabled.
Press the J key to increment the counter. Observe that you get a system beep and that nothing happens, as one would expect.
Check the Enable Menu Items checkbox.
Open the File menu, and observe that the four menu items are enabled.
Try to increment the counter with the ⌘J and J keyboard shortcuts, and to decrement the counter with the ⌘K and K keyboard shortcuts.

Expected result: One would expect that all four keyboard shortcuts (⌘J, J, ⌘K, and K) work again.

Actual result: ⌘J and ⌘K work. When you press J or K, you get a system beep and nothing happens, as if validateMenuItem(_:) was still returning false.

Another way to see the issue:

Run the sample app.
Take note of the Increment/Decrement Counter menu items in the File menu.
Increment the counter with the ⌘J and J keyboard shortcuts. Decrement the counter with the ⌘K and K keyboard shortcuts. Observe that all four keyboard shortcuts work as one would expect.
Press the L key. The system beeps because nothing should handle that key press.
Press the J or K key a few times.

Expected result: One would expect the J key presses to increment the counter, and the K presses to decrement the counter.

Actual result: The very first J or K key press after pressing L might work as expected. After that, pressing either J and K will consistently result in nothing happening, except for the system beeping.

Updated 2026-05-12 at 5:30 PM Boston time: After learning more about the symptoms, I added that pressing a key (such as L) without a corresponding keyboard shortcut also triggers the issue.

Updated 2026-06-11: Added that this issue also exists in macOS 27.

Murder

2026-01-12T10:13:51-05:00

In July, a man died less than two miles from my home while being pinned to the ground by police officers. The police had been called because the man was acting erratically and having some sort of health event. I was deeply concerned, and I wanted a thorough investigation of the incident. If the police officers used excessive force or acted with ill intent, I want them to be held accountable.

There were a number of protests in the area shortly after this incident. I decided not to attend them. I anticipated that some attendees of those protests would accuse the police officers of murder. Since the deceased seemed to be having a health event before police were called, I did not know whether the police were to blame. Therefore I did not want to participate in a protest that might make such accusations.

I was also confident that there would be a thorough investigation. I hope that this confidence was well placed.

The death of Renee Nicole Good is a very different situation. The administration has made it clear that they are avoiding investigation. The FBI is trying to block state and local officials from investigating. I hope that state and local officials are able to investigate and prosecute despite this, but I am skeptical.

JD Vance suggests that we watch video of the incident, so I did. I also watched several breakdowns of the video footage:

Based on all that video footage, it looks like the car was moving slowly and away from the ICE thug. It also like looks the ICE thug walks away without a scratch from this slow-moving vehicle. It looks like he was in about as much danger as he would be walking through any grocery store parking lot. Based on the words uttered just after the shooting, it sounds like he shot her out of unwarranted anger — not out of self-defense.

This was a murder.