Summary
Follow-up from the #1233 reviews (merged). The divergence chrome-filter over-filtering live-evidence requirement (does the filter wrongly drop legit app/actionable controls?) could not be produced end-to-end with the current RN test-app, because the fixtures don't create the states the exemptions target. These are test-fixture gaps, not product bugs — capturing them so the over-filtering guards can be validated on the production divergence route rather than unit-only.
Fixture gaps
1. Short-content screen with a focused input + app control (iOS "accessory survives within 20 refs").
The accessory buttons survive collectSettleChromeRefs (verified on a real device tree), but the field-accessory-input lives at the bottom of the dense Checkout form, so in a live get/is/wait divergence the app controls ahead of it fill the SCREEN_REF_CAPTURE_LIMIT (20) and the accessory is truncated by the cap, not by filtering. A minimal screen (one focused field + a couple of app-owned controls, well under 20 interactive nodes) would let a divergence payload actually show the app-owned control retained within 20 with the keyboard up.
2. Native-UIKit inputAccessoryView hosted inside the keyboard window (iOS geometric exemption).
RN's <InputAccessoryView> renders in a separate window from UIRemoteKeyboardWindow, so the whole-window keyboard classifier never sweeps it — meaning the geometric exemption collectKeyboardAccessoryIndexes (the actual over-filter guard, which keeps a control whose center sits above the keyboard container's top edge inside the keyboard window) is never exercised by any RN fixture. A native accessory-view fixture (a small UIKit host, or an Expo config-plugin/native module that sets a real inputAccessoryView on a UITextField) is required to exercise that exemption live. It stays unit-covered otherwise.
3. A runtime-permission action (Android permission dialog surviving the filter).
The test-app declares no dangerous runtime permission, so there is no permission dialog to raise. A screen that requests one (e.g. camera/mic via expo-camera/expo-av) would let a divergence capture a com.google.android.permissioncontroller dialog surviving the Android settle-chrome filter (foreign-package dialogs are kept by design). Note the actionable-com.android.systemui survival case is separately blocked by #1251 (systemui classification is inert in the non-raw divergence capture until that lands).
Why it matters
With these fixtures, the over-filtering live cases the #1233 reviews asked for become producible on the real divergence route, closing the gap between "unit-covered + reasoned structurally absent for RN" and "device-facing evidence". Lower priority than #1251 (which is a real product bug); this is test-infrastructure.
Summary
Follow-up from the #1233 reviews (merged). The divergence chrome-filter over-filtering live-evidence requirement (does the filter wrongly drop legit app/actionable controls?) could not be produced end-to-end with the current RN test-app, because the fixtures don't create the states the exemptions target. These are test-fixture gaps, not product bugs — capturing them so the over-filtering guards can be validated on the production divergence route rather than unit-only.
Fixture gaps
1. Short-content screen with a focused input + app control (iOS "accessory survives within 20 refs").
The accessory buttons survive
collectSettleChromeRefs(verified on a real device tree), but thefield-accessory-inputlives at the bottom of the dense Checkout form, so in a liveget/is/waitdivergence the app controls ahead of it fill theSCREEN_REF_CAPTURE_LIMIT(20) and the accessory is truncated by the cap, not by filtering. A minimal screen (one focused field + a couple of app-owned controls, well under 20 interactive nodes) would let a divergence payload actually show the app-owned control retained within 20 with the keyboard up.2. Native-UIKit
inputAccessoryViewhosted inside the keyboard window (iOS geometric exemption).RN's
<InputAccessoryView>renders in a separate window fromUIRemoteKeyboardWindow, so the whole-window keyboard classifier never sweeps it — meaning the geometric exemptioncollectKeyboardAccessoryIndexes(the actual over-filter guard, which keeps a control whose center sits above the keyboard container's top edge inside the keyboard window) is never exercised by any RN fixture. A native accessory-view fixture (a small UIKit host, or an Expo config-plugin/native module that sets a realinputAccessoryViewon aUITextField) is required to exercise that exemption live. It stays unit-covered otherwise.3. A runtime-permission action (Android permission dialog surviving the filter).
The test-app declares no dangerous runtime permission, so there is no permission dialog to raise. A screen that requests one (e.g. camera/mic via
expo-camera/expo-av) would let a divergence capture acom.google.android.permissioncontrollerdialog surviving the Android settle-chrome filter (foreign-package dialogs are kept by design). Note the actionable-com.android.systemuisurvival case is separately blocked by #1251 (systemui classification is inert in the non-raw divergence capture until that lands).Why it matters
With these fixtures, the over-filtering live cases the #1233 reviews asked for become producible on the real divergence route, closing the gap between "unit-covered + reasoned structurally absent for RN" and "device-facing evidence". Lower priority than #1251 (which is a real product bug); this is test-infrastructure.