Why Golden Gate may not change focus correctly

Since upgrading to macOS 27.0 Golden Gate I have noticed problems in the GUI with focus, as I have explained. Those arise when I click on a selectable item in the front window, and it becomes selected but isn’t brought into focus. Here’s an extreme example from the Finder in 27.0.1.

I first selected the folder at the left, which is fully highlighted and in focus. I then selected two folders deeper from that, to the file at the right. Although those are highlighted in grey, as they would be when not in focus, QuickLook shows a preview of the file at the right. But if I then press the Down arrow key, full selection and focus move down the items in the column at the left, to the file 0annotations.aar. That’s unexpected and fundamentally incorrect behaviour for any version of the Mac operating system.

To investigate this, I performed two selections in the Finder, in one positioning the pointer so this bizarre semi-selection occurred, and in the other so the same item became both selected in colour and brought into focus. I then compared the two log records.

Initial mention of my actions was identical in both records:
0.383016 Plugin-E Howard N’s Magic Trackpad com.apple.Multitouch [TP] Dispatching digitizer event with 2 children, _eventMask=0x63 _childEventMask=0x43 Cancel=0 Touching=1 inRange=1

That led to an identical input event handled by PKGCore:
0.431448 com.apple.PKGCore [1d] input event: beginDeferredActivation((1073.140625, 99.5078125), hitPSN: Optional(PKGCore.ProcessSerialNumber(hi: 0, lo: 81940)), startEventTime: 506371219830833, source: mouse)

That event was handed on to AppKit:
0.435831 com.apple.PKGCore [1d] input event: deferredActivation(count: 0, activate: false, order: false, time: 506371219830458)
0.437526 com.apple.AppKit Marking view [private] as exclusive.

AppKit then proceeded through a sequence of entries in which it recognised my clicks. This was where the differences appeared. Missing from the semi-selection were entries in which the state was set to Began, seen only in the full selection and focus:
0.437709 com.apple.AppKit Delaying event [[private]]
0.437722 com.apple.AppKit Setting [private] state to Began

A little later, another three entries were missing from semi-selection, again related to the Began phase:
0.437900 com.apple.AppKit gestureNode:didUpdatePhase(.Began), [private]
0.437930 com.apple.AppKit [private]: performing action for state Began
0.437983 com.apple.AppKit gestureNode:didUpdatePhase(.Possible), [private]

Despite those differences, AppKit explicitly recognised the click, in entries common to both records:
0.438148 com.apple.AppKit [0x7cc7952a00 _mouseUp] A new Click, huzzah! count:1 needed:1
0.438148 com.apple.AppKit [0x7cc7952a00 _mouseUp] correct number of clicks - SUCCESS
0.438163 com.apple.AppKit [0x7cc7953000 _mouseUp] A new Click, huzzah! count:1 needed:2
0.438178 com.apple.AppKit [0x7cd04a9000 _mouseUp] A new Click, huzzah! count:1 needed:1
0.438178 com.apple.AppKit [0x7cd04a9000 _mouseUp] correct number of clicks - SUCCESS

At the end of this sequence of entries from AppKit, another two were omitted from the semi-selection, so the click was never Cancelled:
0.438266 com.apple.AppKit gestureNode:didUpdatePhase(.Cancelled), [private]
0.438274 com.apple.AppKit [private]: performing action for state Cancelled

Despite those differences, the Finder recorded its usual double-entry for sendAction, and QuickLook immediately started loading the preview to display in the Finder window:
0.438308 Finder sendAction:
0.440721 Finder sendAction:
0.440976 com.apple.quicklook start loading item [private]

seen in both records.

That evidence implies that the failure to change focus resulted from a bug in AppKit, which in those specific circumstances didn’t go through the correct state changes, omitting Began, Possible and Cancelled. The Finder still selected the item I had clicked, and passed that to QuickLook for its preview, but failed to change the focus, affecting future actions.

This is supported by the ingenious workaround devised by Philip Savoulidis, which manually brings an NSTableView into focus when it’s clicked to select it.

This bug isn’t consistent, though. While I experience it frequently in the Finder, and it affected a SwiftUI List view in LogUI, others have different experience, and many haven’t come across it in the Finder at all. I have several other apps that use List views in SwiftUI, but LogUI is the only app so affected.

Given the strong rumours that Apple is about to announce a touchscreen MacBook Pro, I wonder if there are been provisions made to support that in AppKit resulting in a new bug.