fix(ios): a text field under the software keyboard reports focused in the snapshot

Merged
OK
1mo ago
+62-11

Summary

A text field the software keyboard was typing into never reported focused in an iOS snapshot.

Both focus reads asked for hasFocus, the focus engine's attribute (tvOS, keyboard navigation); the field under a software keyboard holds hasKeyboardFocus instead, which the text-entry readiness check already consults. snapshotHasFocus (RunnerTests+SnapshotAcquisition.swift, the recursive-tree producer) and elementHasFocus (RunnerTests+TvRemote.swift, the query-sweep and collapsed-tab element read) now share one reader, focusBool, which answers hasKeyboardFocus || hasFocus through KVC and reads a missing key as false. The wire shape is unchanged: focused is still true or absent.

The private-AX bridge is untouched: the AX server declares HasNativeFocus and FocusedApplications and no keyboard-focus attribute, so that fallback cannot see keyboard focus and gets no speculative code for it.

3 files, runner only. Android already reports focus.

Validation

Tested at the pushed head, on main. pnpm check:xctest-selection, pnpm check:packaged-runner-swift, and pnpm check:affected --run --base c31cc49f6 passed.

testFocusBoolReadsKeyboardFocusBesideTheFocusEnginesFocus (host lane) drives the shared reader from KVC fixtures: both keys in every combination, each key alone with the other absent, and no key at all. It passes on the booted iPhone 17 Pro simulator via xcodebuild test-without-building.

Live on that simulator, React Native app: after tapping name-input, snapshot --json reports the keyboard visible and exactly one focused node:

name-input: { focused: true, value: 'Ada Lovelace', type: 'TextField' }

Before the change the same snapshot reported no focused node.

Risk: a field with keyboard focus gains focused, so an unchanged comparison across a focus change now reports it.