fix(iOS, Tabs): don't drop user selection of UISearchTab on mount transactions - #4862

…nsactions (#4862) (#4866)

## Description

On the `UITab` API path (iOS 26.1+), once a tab with `role: 'search'`
has been activated (`automaticallyActivatesSearch` with a search bar in
the nested stack header), later user selections of that tab can be
dropped: UIKit shows the search tab selected, but `onTabSelected` is
never sent and JS stays on the previous tab.

`tabBarController:didSelectTab:previousTab:` fires for both user and
programmatic selections, so user selections were detected with a flag
set in `tabBarController:shouldSelectTab:` and consumed in
`didSelectTab:`. Every container update (`-performContainerUpdate`, run
after each Fabric mount transaction) cleared that flag. On iOS 27, once
search has been activated, UIKit lets a mount transaction run between
`shouldSelectTab:` and `didSelectTab:` - the flag is cleared and the
user selection is treated as programmatic.

This PR inverts the filter: the controller marks its own `setTabs:` /
`selectedTab` writes - UIKit sends `didSelectTab:` synchronously from
inside them (verified at runtime and in the UIKitCore disassembly on iOS
26.1 and 27.0) - and treats every other `didSelectTab:` as a user
selection. No flag stays set across the asynchronous should -> did
window anymore.

Reported in #4855, with the first fix proposed in #4856, by @zhelezkov -
thank you! The scenario steps and the "Selected in JS" readout of the v4
test come from #4856.

Closes #4855.

## Changes

- `RNSTabBarController`: replace `_isHandlingUserTabSelection` (set in
`shouldSelectTab:`, cleared on every container update) with
`_isApplyingProgrammaticTabSelection`, set around the controller's own
`setTabs:` / `selectedTab` writes and checked in `didSelectTab:`.
- `test-tabs-search-tab-activation-ios` (Stack v4 & tabs): JS-side
selection readout on the List screen, scenario steps for returning
through the collapsed tab bar, and an e2e test for that flow.
- New `test-tabs-navigation-state-search-tab` (tabs): verifies that each
user and programmatic selection of a search-role tab advances the
navigation state exactly once with the right action origin, with an e2e
test. It hosts no search controller, so it does not reproduce #4855
itself - it guards the programmatic-selection filtering this fix relies
on.

## Test plan

e2e (Detox, `ios.sim.release`, iPhone 17):

-

`FabricExample/e2e/component-integration-tests/tabs-stack-v4/test-tabs-search-tab-activation-ios.e2e.ts`
- iOS 27.0: fails without the fix ("Selected in JS: no" after
reselecting the search tab), passes with it.
- iOS 26.5: passes with and without the fix - the race was not observed
on iOS 26.x, so CI (iOS 26.x for now) does not guard it until it moves
to iOS 27.
-

`FabricExample/e2e/single-feature-tests/tabs/test-tabs-navigation-state-search-tab.e2e.ts`
- passes with the fix on iOS 27.0 and 26.5.
-

`FabricExample/e2e/single-feature-tests/tabs/test-tabs-simple-nav.e2e.ts`
- passes with the fix on iOS 27.0 and 26.5.

Manual, `test-tabs-search-tab-activation-ios` (Component Integration
Tests -> Stack V4 & Native Tabs), iOS 27.0 simulator, without the fix:

1. Enable `automaticallyActivatesSearch`.
2. Tap the search tab, dismiss the keyboard by dragging the list, tap
the collapsed `Config` button.
3. Tap the search tab again and check "Selected in JS" on the List
screen.

Without the fix 5 of 5 reselections showed "Selected in JS: no"; with
the fix the e2e loop above passes.

## Checklist

- [x] Included code example that can be used to test this change.
- [ ] For visual changes, included screenshots / GIFs / recordings
documenting the change.
- [ ] For API changes, updated relevant public types.
- [ ] Ensured that CI passes

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Co-authored-by: Nick Zhelezkov
<[email protected]>
Co-authored-by: Claude Opus 5.5 <[email protected]>
(cherry picked from commit 6430b67)

Co-authored-by: Kacper Kafara <[email protected]>
Co-authored-by: Nick Zhelezkov <[email protected]>
Co-authored-by: Claude Opus 5.5 <[email protected]>

…on while More is active (#4890)

(generated by Claude)

## Description

On the `UITab` API path (iOS 26.1+) a programmatic tab selection made
while the More tab is active emits `onTabSelected` twice: a
`user`-origin event first, then the `programmatic-js` one, and the
navigation state provenance skips a value. It happens when the current
tab overflows into More and was itself selected programmatically (e.g.
`Select Sixth` from JS, then `Select Second`). Entering More through the
More list and then selecting programmatically gives a single event.
Found during the 4.30.0 release testing (#4884), regression from #4862;
4.29.0 and 4.28.0 emit one event.

Root cause: `-[RNSTabBarController applySelectedScreenController:]` sets
`_isApplyingProgrammaticTabSelection` only around `self.selectedTab =
…`, the branch taken when the More item is NOT selected. While More is
selected it falls back to `[self setSelectedViewController:]` without
the flag. UIKit sends `tabBarController:didSelectTab:previousTab:`
synchronously from inside that write, and since #4862 every unflagged
`didSelectTab:` is treated as a user selection:
`userDidSelectViewController:` progresses the state once more and emits
a `user` event, after which the programmatic path emits its own event
with the already-bumped provenance. Before #4862 the filter worked the
other way round (flag set in `shouldSelectTab:`), so the programmatic
`setSelectedViewController:` write was ignored.

## Changes

- `RNSTabBarController -applySelectedScreenController:`:
`_isApplyingProgrammaticTabSelection` now wraps the whole `UITab`
branch, including the `setSelectedViewController:` fallback used while
More is active. Same pattern as `installScreenControllers:` around
`setTabs:` / `selectedTab`.

## Before & after - visual documentation

| Before | After |
| --- | --- |
| <video
src="https://github.com/user-attachments/assets/3336fc09-d892-4436-acd4-9b6d8fef900a"
/> | <video
src="https://github.com/user-attachments/assets/a3e3e738-3a59-4afb-bec5-d10ccdeac7b6"
/> |

## Test plan

- `tabs/test-tabs-more-navigation-controller-ios` (SFT), iPhone
simulator, iOS 27.0 and 26.5: `Select Sixth`, then `Select Second`.
Before: two `onTabSelected` toasts for `Second`; after: one, with the
provenance advanced by exactly one (check the `onTabSelected` payload).
Also More → Fifth → `Select First` (one event, unchanged) and user taps
between More and regular tabs (unchanged).
- `tabs-stack-v4/test-tabs-search-tab-activation-ios` on iOS 27.0, the
#4862 scenario: reselecting the search tab through the collapsed tab bar
still shows "Selected in JS: yes".
- `tabs/test-tabs-navigation-state-search-tab` and
`tabs/test-tabs-simple-nav` e2e: unchanged.

Draft: the root cause comes from the triage done for #4884 (A/B against
4.28.0 / 4.29.0 / 4.30 with the same app and only the library sources
swapped), the patch builds (Debug) but has not been run against the
scenario yet.

## Checklist

- [x] Included code example that can be used to test this change
(`tabs/test-tabs-more-navigation-controller-ios`).
- [ ] For visual changes, included screenshots / GIFs / recordings
documenting the change.
- [ ] For API changes, updated relevant public types.
- [ ] Ensured that CI passes

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: Claude Fable 5.1 <[email protected]>

…on while More is active (#4890) (#4892)

(generated by Claude)

## Description

On the `UITab` API path (iOS 26.1+) a programmatic tab selection made
while the More tab is active emits `onTabSelected` twice: a
`user`-origin event first, then the `programmatic-js` one, and the
navigation state provenance skips a value. It happens when the current
tab overflows into More and was itself selected programmatically (e.g.
`Select Sixth` from JS, then `Select Second`). Entering More through the
More list and then selecting programmatically gives a single event.
Found during the 4.30.0 release testing (#4884), regression from #4862;
4.29.0 and 4.28.0 emit one event.

Root cause: `-[RNSTabBarController applySelectedScreenController:]` sets
`_isApplyingProgrammaticTabSelection` only around `self.selectedTab =
…`, the branch taken when the More item is NOT selected. While More is
selected it falls back to `[self setSelectedViewController:]` without
the flag. UIKit sends `tabBarController:didSelectTab:previousTab:`
synchronously from inside that write, and since #4862 every unflagged
`didSelectTab:` is treated as a user selection:
`userDidSelectViewController:` progresses the state once more and emits
a `user` event, after which the programmatic path emits its own event
with the already-bumped provenance. Before #4862 the filter worked the
other way round (flag set in `shouldSelectTab:`), so the programmatic
`setSelectedViewController:` write was ignored.

## Changes

- `RNSTabBarController -applySelectedScreenController:`:
`_isApplyingProgrammaticTabSelection` now wraps the whole `UITab`
branch, including the `setSelectedViewController:` fallback used while
More is active. Same pattern as `installScreenControllers:` around
`setTabs:` / `selectedTab`.

## Before & after - visual documentation

| Before | After |
| --- | --- |
| <video

src="https://github.com/user-attachments/assets/3336fc09-d892-4436-acd4-9b6d8fef900a"
/> | <video

src="https://github.com/user-attachments/assets/a3e3e738-3a59-4afb-bec5-d10ccdeac7b6"
/> |

## Test plan

- `tabs/test-tabs-more-navigation-controller-ios` (SFT), iPhone
simulator, iOS 27.0 and 26.5: `Select Sixth`, then `Select Second`.
Before: two `onTabSelected` toasts for `Second`; after: one, with the
provenance advanced by exactly one (check the `onTabSelected` payload).
Also More → Fifth → `Select First` (one event, unchanged) and user taps
between More and regular tabs (unchanged).
- `tabs-stack-v4/test-tabs-search-tab-activation-ios` on iOS 27.0, the
#4862 scenario: reselecting the search tab through the collapsed tab bar
still shows "Selected in JS: yes".
- `tabs/test-tabs-navigation-state-search-tab` and
`tabs/test-tabs-simple-nav` e2e: unchanged.

Draft: the root cause comes from the triage done for #4884 (A/B against
4.28.0 / 4.29.0 / 4.30 with the same app and only the library sources
swapped), the patch builds (Debug) but has not been run against the
scenario yet.

## Checklist

- [x] Included code example that can be used to test this change
(`tabs/test-tabs-more-navigation-controller-ios`).
- [ ] For visual changes, included screenshots / GIFs / recordings
documenting the change.
- [ ] For API changes, updated relevant public types.
- [ ] Ensured that CI passes

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: Claude Fable 5.1 <[email protected]>
(cherry picked from commit 4a87a71)

Co-authored-by: Claude Fable 5.1 <[email protected]>

…on while More is active (#4890) (#4892) (#4894)

(generated by Claude)

## Description

On the `UITab` API path (iOS 26.1+) a programmatic tab selection made
while the More tab is active emits `onTabSelected` twice: a
`user`-origin event first, then the `programmatic-js` one, and the
navigation state provenance skips a value. It happens when the current
tab overflows into More and was itself selected programmatically (e.g.
`Select Sixth` from JS, then `Select Second`). Entering More through the
More list and then selecting programmatically gives a single event.
Found during the 4.30.0 release testing (#4884), regression from #4862;
4.29.0 and 4.28.0 emit one event.

Root cause: `-[RNSTabBarController applySelectedScreenController:]` sets
`_isApplyingProgrammaticTabSelection` only around `self.selectedTab =
…`, the branch taken when the More item is NOT selected. While More is
selected it falls back to `[self setSelectedViewController:]` without
the flag. UIKit sends `tabBarController:didSelectTab:previousTab:`
synchronously from inside that write, and since #4862 every unflagged
`didSelectTab:` is treated as a user selection:
`userDidSelectViewController:` progresses the state once more and emits
a `user` event, after which the programmatic path emits its own event
with the already-bumped provenance. Before #4862 the filter worked the
other way round (flag set in `shouldSelectTab:`), so the programmatic
`setSelectedViewController:` write was ignored.

## Changes

- `RNSTabBarController -applySelectedScreenController:`:
`_isApplyingProgrammaticTabSelection` now wraps the whole `UITab`
branch, including the `setSelectedViewController:` fallback used while
More is active. Same pattern as `installScreenControllers:` around
`setTabs:` / `selectedTab`.

## Before & after - visual documentation

| Before | After |
| --- | --- |
| <video


src="https://github.com/user-attachments/assets/3336fc09-d892-4436-acd4-9b6d8fef900a"
/> | <video


src="https://github.com/user-attachments/assets/a3e3e738-3a59-4afb-bec5-d10ccdeac7b6"
/> |

## Test plan

- `tabs/test-tabs-more-navigation-controller-ios` (SFT), iPhone
simulator, iOS 27.0 and 26.5: `Select Sixth`, then `Select Second`.
Before: two `onTabSelected` toasts for `Second`; after: one, with the
provenance advanced by exactly one (check the `onTabSelected` payload).
Also More → Fifth → `Select First` (one event, unchanged) and user taps
between More and regular tabs (unchanged).
- `tabs-stack-v4/test-tabs-search-tab-activation-ios` on iOS 27.0, the
#4862 scenario: reselecting the search tab through the collapsed tab bar
still shows "Selected in JS: yes".
- `tabs/test-tabs-navigation-state-search-tab` and
`tabs/test-tabs-simple-nav` e2e: unchanged.

Draft: the root cause comes from the triage done for #4884 (A/B against
4.28.0 / 4.29.0 / 4.30 with the same app and only the library sources
swapped), the patch builds (Debug) but has not been run against the
scenario yet.

## Checklist

- [x] Included code example that can be used to test this change
(`tabs/test-tabs-more-navigation-controller-ios`).
- [ ] For visual changes, included screenshots / GIFs / recordings
documenting the change.
- [ ] For API changes, updated relevant public types.
- [ ] Ensured that CI passes

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: Claude Fable 5.1 <[email protected]>
(cherry picked from commit 4a87a71)

Co-authored-by: Claude Fable 5.1 <[email protected]>
(cherry picked from commit 30c0cfe)

Co-authored-by: Claude Fable 5.1 <[email protected]>

…nsactions (software-mansion#4862)

## Description

On the `UITab` API path (iOS 26.1+), once a tab with `role: 'search'`
has been activated (`automaticallyActivatesSearch` with a search bar in
the nested stack header), later user selections of that tab can be
dropped: UIKit shows the search tab selected, but `onTabSelected` is
never sent and JS stays on the previous tab.

`tabBarController:didSelectTab:previousTab:` fires for both user and
programmatic selections, so user selections were detected with a flag
set in `tabBarController:shouldSelectTab:` and consumed in
`didSelectTab:`. Every container update (`-performContainerUpdate`, run
after each Fabric mount transaction) cleared that flag. On iOS 27, once
search has been activated, UIKit lets a mount transaction run between
`shouldSelectTab:` and `didSelectTab:` - the flag is cleared and the
user selection is treated as programmatic.

This PR inverts the filter: the controller marks its own `setTabs:` /
`selectedTab` writes - UIKit sends `didSelectTab:` synchronously from
inside them (verified at runtime and in the UIKitCore disassembly on iOS
26.1 and 27.0) - and treats every other `didSelectTab:` as a user
selection. No flag stays set across the asynchronous should -> did
window anymore.

Reported in software-mansion#4855, with the first fix proposed in software-mansion#4856, by @zhelezkov -
thank you! The scenario steps and the "Selected in JS" readout of the v4
test come from software-mansion#4856.

Closes software-mansion#4855.

## Changes

- `RNSTabBarController`: replace `_isHandlingUserTabSelection` (set in
`shouldSelectTab:`, cleared on every container update) with
`_isApplyingProgrammaticTabSelection`, set around the controller's own
`setTabs:` / `selectedTab` writes and checked in `didSelectTab:`.
- `test-tabs-search-tab-activation-ios` (Stack v4 & tabs): JS-side
selection readout on the List screen, scenario steps for returning
through the collapsed tab bar, and an e2e test for that flow.
- New `test-tabs-navigation-state-search-tab` (tabs): verifies that each
user and programmatic selection of a search-role tab advances the
navigation state exactly once with the right action origin, with an e2e
test. It hosts no search controller, so it does not reproduce software-mansion#4855
itself - it guards the programmatic-selection filtering this fix relies
on.

## Test plan

e2e (Detox, `ios.sim.release`, iPhone 17):

-
`FabricExample/e2e/component-integration-tests/tabs-stack-v4/test-tabs-search-tab-activation-ios.e2e.ts`
- iOS 27.0: fails without the fix ("Selected in JS: no" after
reselecting the search tab), passes with it.
- iOS 26.5: passes with and without the fix - the race was not observed
on iOS 26.x, so CI (iOS 26.x for now) does not guard it until it moves
to iOS 27.
-
`FabricExample/e2e/single-feature-tests/tabs/test-tabs-navigation-state-search-tab.e2e.ts`
- passes with the fix on iOS 27.0 and 26.5.
-
`FabricExample/e2e/single-feature-tests/tabs/test-tabs-simple-nav.e2e.ts`
- passes with the fix on iOS 27.0 and 26.5.

Manual, `test-tabs-search-tab-activation-ios` (Component Integration
Tests -> Stack V4 & Native Tabs), iOS 27.0 simulator, without the fix:

1. Enable `automaticallyActivatesSearch`.
2. Tap the search tab, dismiss the keyboard by dragging the list, tap
the collapsed `Config` button.
3. Tap the search tab again and check "Selected in JS" on the List
screen.

Without the fix 5 of 5 reselections showed "Selected in JS: no"; with
the fix the e2e loop above passes.

## Checklist

- [x] Included code example that can be used to test this change.
- [ ] For visual changes, included screenshots / GIFs / recordings
documenting the change.
- [ ] For API changes, updated relevant public types.
- [ ] Ensured that CI passes

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Co-authored-by: Nick Zhelezkov <[email protected]>
Co-authored-by: Claude Opus 5.5 <[email protected]>
(cherry picked from commit 6430b67)

…on while More is active (software-mansion#4890)

(generated by Claude)

## Description

On the `UITab` API path (iOS 26.1+) a programmatic tab selection made
while the More tab is active emits `onTabSelected` twice: a
`user`-origin event first, then the `programmatic-js` one, and the
navigation state provenance skips a value. It happens when the current
tab overflows into More and was itself selected programmatically (e.g.
`Select Sixth` from JS, then `Select Second`). Entering More through the
More list and then selecting programmatically gives a single event.
Found during the 4.30.0 release testing (software-mansion#4884), regression from software-mansion#4862;
4.29.0 and 4.28.0 emit one event.

Root cause: `-[RNSTabBarController applySelectedScreenController:]` sets
`_isApplyingProgrammaticTabSelection` only around `self.selectedTab =
…`, the branch taken when the More item is NOT selected. While More is
selected it falls back to `[self setSelectedViewController:]` without
the flag. UIKit sends `tabBarController:didSelectTab:previousTab:`
synchronously from inside that write, and since software-mansion#4862 every unflagged
`didSelectTab:` is treated as a user selection:
`userDidSelectViewController:` progresses the state once more and emits
a `user` event, after which the programmatic path emits its own event
with the already-bumped provenance. Before software-mansion#4862 the filter worked the
other way round (flag set in `shouldSelectTab:`), so the programmatic
`setSelectedViewController:` write was ignored.

## Changes

- `RNSTabBarController -applySelectedScreenController:`:
`_isApplyingProgrammaticTabSelection` now wraps the whole `UITab`
branch, including the `setSelectedViewController:` fallback used while
More is active. Same pattern as `installScreenControllers:` around
`setTabs:` / `selectedTab`.

## Before & after - visual documentation

| Before | After |
| --- | --- |
| <video
src="https://github.com/user-attachments/assets/3336fc09-d892-4436-acd4-9b6d8fef900a"
/> | <video
src="https://github.com/user-attachments/assets/a3e3e738-3a59-4afb-bec5-d10ccdeac7b6"
/> |

## Test plan

- `tabs/test-tabs-more-navigation-controller-ios` (SFT), iPhone
simulator, iOS 27.0 and 26.5: `Select Sixth`, then `Select Second`.
Before: two `onTabSelected` toasts for `Second`; after: one, with the
provenance advanced by exactly one (check the `onTabSelected` payload).
Also More → Fifth → `Select First` (one event, unchanged) and user taps
between More and regular tabs (unchanged).
- `tabs-stack-v4/test-tabs-search-tab-activation-ios` on iOS 27.0, the
software-mansion#4862 scenario: reselecting the search tab through the collapsed tab bar
still shows "Selected in JS: yes".
- `tabs/test-tabs-navigation-state-search-tab` and
`tabs/test-tabs-simple-nav` e2e: unchanged.

Draft: the root cause comes from the triage done for software-mansion#4884 (A/B against
4.28.0 / 4.29.0 / 4.30 with the same app and only the library sources
swapped), the patch builds (Debug) but has not been run against the
scenario yet.

## Checklist

- [x] Included code example that can be used to test this change
(`tabs/test-tabs-more-navigation-controller-ios`).
- [ ] For visual changes, included screenshots / GIFs / recordings
documenting the change.
- [ ] For API changes, updated relevant public types.
- [ ] Ensured that CI passes

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: Claude Fable 5.1 <[email protected]>
(cherry picked from commit 4a87a71)

Brings upstream's fix for user tab selections dropped by a mount
transaction (software-mansion#4862, software-mansion#4890) and the opt-in horizontal sheet bars from software-mansion#2.

Co-Authored-By: Claude Opus 5.5 <[email protected]>