[Due for payment 2026-06-26] [$250] iOS - Agent - Blank screen appears briefly when navigating back from the Edit avatar screen

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: v9.4.5-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #92002
Email or phone of affected tester (no customers): n/a
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: iPhone 13 iOS 26.5
App Component: Other

Action Performed:

Precondition: Login with expensifail accound and create an agent.

1. Open the app
2. Go to Account
3. Tap the 2 arrow icon next to the account section
4. Select an Agent
5. Go to Profile
6. Tap the avatar
7. Tap the back button

Expected Result:

The previous screen should be displayed immediately when navigating back from the Edit avatar screen, without showing a blank screen.

Actual Result:

Blank screen appears briefly when navigating back from the Edit avatar screen

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome Safari

Screenshots/Videos

To be added by Applause Leads

Bug7177575_1781152761143.ScreenRecording_06-10-2026_23-38-16_1.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Iuliia Herets
Bug ID: 7177575

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022064979539305727263
• Upwork Job ID: 2064979539305727263
• Last Price Increase: 2026-06-11
• Automatic offers:
• thelullabyy | Reviewer | 111695403

Issue Owner

Current Issue Owner: @mallenexpensify

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/728fda3cfa5a061f28ee0fe06e846bece7143a585966b45b4674eb663f7744d2

[MelvinBot]

Proposal

Confidence: Medium — root cause is well-supported by code evidence but not yet confirmed on an iOS simulator. The one-line confirmation test is in the collapsed section below.

What is the root cause of that problem?

The blank flash is not specific to the Agent flow and not caused by the recently-merged PR #92002 (that PR is a pure avatar-catalog rename — it touches no navigator/screen code, and this bug reproduces in production). It's a pre-existing iOS-native navigation-transition glitch.

Tapping the profile avatar opens the avatar editor as an RHP modal (SETTINGS_AVATAR → AvatarPage) on top of ProfilePage, which lives in the SettingsSplitNavigator. That split navigator sets freezeNonTopScreens: true, so while the RHP is open ProfilePage is wrapped in <Freeze> + a CustomViewWrapper.

That CustomViewWrapper is meant to keep the underlay visible during back navigation — its own comment says it exists for "preventing a blank screen flash while navigating between screens" — and it does this by applying display: 'contents' (ScreenFreezeWrapper/index.native.tsx:20-35). On iOS Fabric/UIKit, display: 'contents' is unsupported and silently dropped, so during the RHP slide-out the wrapper is just an opaque RCTView covering the ProfilePage snapshot for a few frames → the brief blank flash. On unfreeze, frozen is set false synchronously in useLayoutEffect, before the underlay has re-painted. Android (Fragments) and web (CSS stack) don't hit this snapshot-timing/display:contents path, which is why it's iOS-App-only.

What changes do you think we should make in order to solve the problem?

In ScreenFreezeWrapper/index.native.tsx, stop depending on the unsupported display: 'contents' shim: defer the unfreeze until the back transition actually finishes instead of flipping frozen = false synchronously in useLayoutEffect. Run the unfreeze after transitions complete (the codebase already has TransitionTracker.runAfterTransitions(...), used in RightModalNavigator), so the underlay snapshot stays painted until iOS hands off, with no blank window.

Because this touches a core, shared navigation primitive, it must be regression-tested across all RHP→Split back navigations and platforms — not just the avatar flow.

Confirmation test, alternatives, and evidence

Cleanest confirmation (one line): flip freezeNonTopScreens to false on a dev iOS build — if the flash disappears, the freeze wrapper is confirmed as the cause. An Xcode View-Hierarchy capture during the ~100–300ms back animation should show CustomViewWrapper as an opaque RCTView over the ProfilePage snapshot.

Alternatives considered:

• Add ProfilePage/split central screens to persistentScreens so they're never frozen — fixes the flash but uses more memory.
• Disable freezeNonTopScreens for the split navigator — removes the flash but gives up the freeze perf benefit. (Use only as the diagnostic toggle above, not the fix.)

Flow / evidence:

• Avatar tap: ProfilePage.tsx:241 → ROUTES.SETTINGS_AVATAR.
• Registered in the Settings RHP stack: ModalStackNavigators/index.tsx:421 as AvatarPage.
• For agents, AvatarPage early-returns EditAgentAvatarContent (AvatarPage.tsx:124-156); the agent body just makes the flash easier to notice — ProfilePage itself does not render null on re-focus.
• Underlay (ProfilePage) registered as the split central screen: SettingsSplitNavigator.tsx:20.
• Wrapper applied to every blurred screen: wrapDescriptorsWithFreeze.tsx:32.

Likely broader scope: QA may be able to reproduce the same flash on other RHP→ProfilePage back navigations (e.g. back from SETTINGS_DISPLAY_NAME), since nothing here is agent-specific.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/93256) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[lorretheboy]

🚨 Edited by proposal-police: This proposal was edited at 2026-06-11 10:44:51 UTC.

Proposal

What is the root cause of that problem?

The avatar screen is reachable at the same route (SETTINGS_AVATAR) for everyone, but it is rendered with two different ScreenWrapper configurations depending on whether the logged-in account is an agent.
For a normal user, ProfileAvatar renders its own ScreenWrapper with shouldEnableMaxHeight:

App/src/pages/settings/Profile/Avatar/AvatarPage.tsx

Lines 158 to 166 in 1ce07c3

	return (
	<ScreenWrapper
	includeSafeAreaPaddingBottom
	includePaddingTop
	shouldEnableMaxHeight
	testID="ProfileAvatar"
	offlineIndicatorStyle={styles.mtAuto}
	shouldShowOfflineIndicatorInWideScreen
	>

For an agent (copiloted-in account), ProfileAvatar short-circuits and instead returns EditAgentAvatarContent:

App/src/pages/settings/Profile/Avatar/AvatarPage.tsx

Lines 150 to 155 in 1ce07c3

	return (
	<EditAgentAvatarContent
	accountID={currentUserPersonalDetails.accountID}
	onSave={handleAgentSave}
	/>
	);

EditAgentAvatarContent wraps its own ScreenWrapper that omits shouldEnableMaxHeight:

App/src/pages/settings/Agents/Fields/EditAgentAvatarPage.tsx

Lines 149 to 154 in 1ce07c3

	return (
	<ScreenWrapper
	testID={EditAgentAvatarContent.displayName}
	includeSafeAreaPaddingBottom
	offlineIndicatorStyle={styles.mtAuto}
	>

shouldEnableMaxHeight is what pins the screen content to the window height; without it the content height stays unconstrained (maxHeight is undefined, falling back to h100):

App/src/components/ScreenWrapper/ScreenWrapperContainer.tsx

Line 122 in 1ce07c3

const maxHeight = shouldEnableMaxHeight ? windowHeight : undefined;

Causal chain: agent account → ProfileAvatar renders EditAgentAvatarContent instead of its own wrapper → that wrapper has no shouldEnableMaxHeight → the screen height isn't pinned during the iOS dismissal animation → the unconstrained layout reflows/collapses for a frame as you swipe/tap back → blank flash before the previous screen settles. Normal users don't hit it because their branch sets shouldEnableMaxHeight.

What changes do you think we should make in order to solve the problem?

Add shouldEnableMaxHeight to the ScreenWrapper inside EditAgentAvatarContent so it matches the non-agent ProfileAvatar branch:

App/src/pages/settings/Agents/Fields/EditAgentAvatarPage.tsx

Lines 149 to 154 in 1ce07c3

	return (
	<ScreenWrapper
	testID={EditAgentAvatarContent.displayName}
	includeSafeAreaPaddingBottom
	offlineIndicatorStyle={styles.mtAuto}
	>

Because EditAgentAvatarContent is the shared component, this single change also covers its other entry points — the route-based EditAgentAvatarPage and AddAgentAvatarPage — keeping the avatar screen height-stable during transitions everywhere.

What alternative solutions did you explore? (Optional)

Instead of editing the shared component, pass the wrapper-config props (e.g. shouldEnableMaxHeight) down from ProfileAvatar into EditAgentAvatarContent, so the agent branch stays visually identical to the normal ProfileAvatar branch. The shared-component fix is preferable since it corrects every call site at once.
Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[dilshodmackbook-sketch]

🚨 Edited by proposal-police: This proposal was edited at 2026-06-11 07:57:09 UTC.

Proposal

Please re-state the problem that we are trying to solve in this issue.

While acting as an Agent (copilot), opening Profile → tapping the avatar → tapping back flashes a blank screen on iOS before the previous screen appears. This is the iOS sibling of #93089 ("Account page becomes blank on browser back after being copiloted"); the fix there was browser-history-only plus a withAgentAccessDenied guard, neither of which covers the edit-avatar path on native.

What is the root cause of that problem?

For an agent session, ProfileAvatar early-returns a separate EditAgentAvatarContent subtree instead of rendering its normal body:

App/src/pages/settings/Profile/Avatar/AvatarPage.tsx

Lines 123 to 155 in 1a8ff38

	if (isAgentAccount) {
	const handleAgentSave = (params: OnSaveParams) => {
	if ('file' in params) {
	updateAvatar(params.file, {
	avatar: currentUserPersonalDetails?.avatar,
	avatarThumbnail: currentUserPersonalDetails?.avatarThumbnail,
	accountID: currentUserPersonalDetails?.accountID,
	});
	} else {
	const {customExpensifyAvatarID} = params;
	const uri = resolveAvatarURI(customExpensifyAvatarID);
	updateAvatar(
	{
	uri,
	name: customExpensifyAvatarID,
	customExpensifyAvatarID,
	},
	{
	avatar: currentUserPersonalDetails?.avatar,
	avatarThumbnail: currentUserPersonalDetails?.avatarThumbnail,
	accountID: currentUserPersonalDetails?.accountID,
	},
	);
	}
	Navigation.dismissModal();
	};
	return (
	<EditAgentAvatarContent
	accountID={currentUserPersonalDetails.accountID}
	onSave={handleAgentSave}
	/>
	);
	}

That means the SETTINGS.PROFILE.AVATAR screen mounts a different ScreenWrapper depending on isAgentAccount. The standard branch is height-constrained with includePaddingTop + shouldEnableMaxHeight:

App/src/pages/settings/Profile/Avatar/AvatarPage.tsx

Lines 157 to 165 in 1a8ff38

	return (
	<ScreenWrapper
	includeSafeAreaPaddingBottom
	includePaddingTop
	shouldEnableMaxHeight
	testID="ProfileAvatar"
	offlineIndicatorStyle={styles.mtAuto}
	shouldShowOfflineIndicatorInWideScreen
	>

…but the agent branch's wrapper has neither:

App/src/pages/settings/Agents/Fields/EditAgentAvatarPage.tsx

Lines 152 to 161 in 1a8ff38

	return (
	<ScreenWrapper
	testID={EditAgentAvatarContent.displayName}
	includeSafeAreaPaddingBottom
	offlineIndicatorStyle={styles.mtAuto}
	>
	<HeaderWithBackButton
	title={translate('editAgentAvatarPage.title')}
	onBackButtonPress={() => Navigation.goBack(fallbackRoute)}
	/>

Without shouldEnableMaxHeight, the screen isn't constrained to the measured available height, so during the iOS back/dismiss transition the modal content momentarily measures to an unconstrained/zero height and the user sees a blank frame. The non-agent avatar screen doesn't flash because its wrapper is already height-constrained. This path is also why #93089's fixes don't help: the avatar screen isn't wrapped by withAgentAccessDenied, and the history-replace is web-only.

What changes do you think we should make in order to solve the problem?

1. Make the agent avatar screen use the same height-constrained, stable container as the standard branch. The smallest change is to add the missing constraints to EditAgentAvatarContent's ScreenWrapper so it matches the normal avatar screen:

  <ScreenWrapper
      testID={EditAgentAvatarContent.displayName}
+     includePaddingTop
+     shouldEnableMaxHeight
      includeSafeAreaPaddingBottom
      offlineIndicatorStyle={styles.mtAuto}
  >

2. EditAgentAvatarContent is also used standalone (the SETTINGS_AGENTS_EDIT_AVATAR route), and these props match what every other full-screen avatar/settings page already uses, so this is consistent rather than path-specific. No behavior change for the standalone agent-edit page beyond correct height constraint.

3. If a flash still remains after this, the fallback is to lift a single shared ScreenWrapper out of the isAgentAccount branch in AvatarPage so the screen container is identical across both branches and only the inner content swaps — eliminating the agent-only remount regardless of which prop triggered it.

What alternative solutions did you explore? (Optional)

Extending #93089's approach (history replacement / withAgentAccessDenied) doesn't apply here: the avatar screen isn't gated by that HOC and native has no browser history to replace, so the blank originates from the screen's own wrapper rather than from landing on a denied route. I also considered guarding Navigation.goBack(fallbackRoute) in EditAgentAvatarContent, but the back target resolves correctly — the issue is the transient height of the agent wrapper, not the destination.

[Abdulloh0109]

Proposal

What is the root cause of that problem?

The "Agent" here is an agent_N@expensify.ai account, detected by useIsAgentAccount (SessionUtils.ts#L111-L123). When you act as one and tap the avatar on Settings > Profile, you go to the same SETTINGS_AVATAR route as everyone else (ProfilePage.tsx#L237-L241). But AvatarPage forks on isAgentAccount: regular users render the local ProfileAvatar editor, agents get EditAgentAvatarContent instead (AvatarPage.tsx#L150-L155).

Those two editors aren't wrapped the same way, and that's the whole bug. The regular editor's ScreenWrapper sets shouldEnableMaxHeight (AvatarPage.tsx#L158-L166). EditAgentAvatarContent's ScreenWrapper does not (EditAgentAvatarPage.tsx#L150-L158).

shouldEnableMaxHeight is what pins the screen content to a fixed windowHeight — maxHeight = shouldEnableMaxHeight ? windowHeight : undefined (ScreenWrapperContainer.tsx#L122) applied on the content view at #L222-L227. Without it the content height falls back to flex / height: 100% resolved against the RHP card. During the iOS native-stack pop the card gets re-measured mid-animation, the unanchored content collapses for a frame, and the transparent stack card (the comment at ScreenWrapperContainer.tsx#L213 literally notes the cards are transparent) shows through — that's the blank flash. It's iOS-only because that's where the pop re-measures the card this way, and agent-only because the agent branch is the one screen that drops shouldEnableMaxHeight.

The back handler is a red herring: the agent editor calls Navigation.goBack(fallbackRoute) with fallbackRoute === undefined, which is identical to the no-arg Navigation.goBack() the regular HeaderWithBackButton uses (goBack(backToRoute?, options?), Navigation.ts#L509). Same back target — the only difference is the ScreenWrapper of the screen being dismissed.

What changes do you think we should make in order to solve the problem?

Render/style layer. Add shouldEnableMaxHeight to the ScreenWrapper in EditAgentAvatarContent (EditAgentAvatarPage.tsx#L150-L154) so the agent editor is height-locked through the transition exactly like the regular ProfileAvatar two lines away.

It's one prop, and it fixes every place that component renders — the Settings > Profile avatar in agent mode, the standalone agent EDIT_AVATAR screen (EditAgentAvatarPage.tsx#L264-L272), and AddAgentAvatarPage, all of which share EditAgentAvatarContent and all of which have the same gap today.

I'd keep it to that one prop. The screen has no text input, so the maxHeight / KeyboardAvoidingView interaction is a non-issue here, and the AvatarCropModal is its own modal. No offline, optimistic-rollback, or empty-state paths are touched.

What alternative solutions did you explore? (Optional)

PR #92002 ("Split out Agent Avatars from User Avatars"), the linked regression-test build. Rejected: it only re-partitioned which avatars appear in the picker catalog — it never touched navigation or ScreenWrapper layout, so reverting it leaves the back-transition unchanged. It's the build the tester happened to be on, not the cause; the bug also reproduces in production, while #92002 only just reached staging (9.4.5-0).

The blank is the revealed Profile page re-rendering after the native-stack freezeOnBlur unfreezes (or the goBack(undefined) call) — i.e. the screen behind, not the one being dismissed. Rejected: freeze/unfreeze fires on every RHP back-navigation, so it can't explain why only the agent avatar screen flashes, and goBack(undefined) is the same pop the working non-agent path performs. If either were the cause, regular users would see the flash too — they don't.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @thelullabyy (External)

[wildan-m]

Proposal

Please re-state the problem that we are trying to solve in this issue.

When signed in as an agent account, opening the avatar editor from Profile and then tapping the back button shows a brief blank screen on iOS before the previous screen appears, instead of returning to it immediately.

What is the root cause of that problem?

The Profile avatar route (SCREENS.SETTINGS.PROFILE.AVATAR) renders the ProfileAvatar component. For agent accounts it short-circuits and renders EditAgentAvatarContent instead of the normal avatar editor:

App/src/pages/settings/Profile/Avatar/AvatarPage.tsx

Lines 124 to 156 in 1ce07c3

	if (isAgentAccount) {
	const handleAgentSave = (params: OnSaveParams) => {
	if ('file' in params) {
	updateAvatar(params.file, {
	avatar: currentUserPersonalDetails?.avatar,
	avatarThumbnail: currentUserPersonalDetails?.avatarThumbnail,
	accountID: currentUserPersonalDetails?.accountID,
	});
	} else {
	const {customExpensifyAvatarID} = params;
	const uri = AGENT_AVATARS.resolveURI(customExpensifyAvatarID);
	updateAvatar(
	{
	uri,
	name: customExpensifyAvatarID,
	customExpensifyAvatarID,
	},
	{
	avatar: currentUserPersonalDetails?.avatar,
	avatarThumbnail: currentUserPersonalDetails?.avatarThumbnail,
	accountID: currentUserPersonalDetails?.accountID,
	},
	);
	}
	Navigation.dismissModal();
	};
	return (
	<EditAgentAvatarContent
	accountID={currentUserPersonalDetails.accountID}
	onSave={handleAgentSave}
	/>
	);
	}

The two render paths wrap their content in ScreenWrapper with different props. The normal (non-agent) path sets shouldEnableMaxHeight:

App/src/pages/settings/Profile/Avatar/AvatarPage.tsx

Lines 159 to 167 in 1ce07c3

	<ScreenWrapper
	includeSafeAreaPaddingBottom
	includePaddingTop
	shouldEnableMaxHeight
	testID="ProfileAvatar"
	offlineIndicatorStyle={styles.mtAuto}
	shouldShowOfflineIndicatorInWideScreen
	>
	<HeaderWithBackButton title={translate('avatarPage.title')} />

but the agent path's ScreenWrapper inside EditAgentAvatarContent does not set it:

App/src/pages/settings/Agents/Fields/EditAgentAvatarPage.tsx

Lines 150 to 153 in 1ce07c3

	<ScreenWrapper
	testID={EditAgentAvatarContent.displayName}
	includeSafeAreaPaddingBottom
	offlineIndicatorStyle={styles.mtAuto}

shouldEnableMaxHeight is what constrains the screen content to the current windowHeight. When it is omitted, maxHeight is undefined, so the content area falls back to h100 (height: 100%) with no concrete height to resolve against:

App/src/components/ScreenWrapper/ScreenWrapperContainer.tsx

Line 122 in 1ce07c3

const maxHeight = shouldEnableMaxHeight ? windowHeight : undefined;

App/src/components/ScreenWrapper/ScreenWrapperContainer.tsx

Line 227 in 1ce07c3

style={[styles.w100, styles.h100, !isBlurred ? {maxHeight} : undefined, isAvoidingViewportScroll ? [styles.overflowAuto, styles.overscrollBehaviorContain] : {}]}

During the iOS back-navigation transition the parent height is momentarily unstable, so the unconstrained content collapses for a frame and a blank screen flashes. The non-agent avatar screen does not show this because its explicit windowHeight cap keeps the content sized through the transition. This regressed in PR #92002, which introduced the agent branch and the separate EditAgentAvatarContent wrapper.

What changes do you think we should make in order to solve the problem?

Add shouldEnableMaxHeight to the ScreenWrapper in EditAgentAvatarContent so the agent avatar editor is constrained to windowHeight exactly like the non-agent avatar screen:

App/src/pages/settings/Agents/Fields/EditAgentAvatarPage.tsx

Lines 150 to 153 in 1ce07c3

	<ScreenWrapper
	testID={EditAgentAvatarContent.displayName}
	includeSafeAreaPaddingBottom
	offlineIndicatorStyle={styles.mtAuto}

With the content capped at the viewport height, it no longer collapses during the iOS back transition, so the previous screen is shown immediately without the blank flash. This also brings the agent avatar editor (used both at the Profile avatar route and the standalone agent edit-avatar route) to parity with the existing avatar screen's wrapper configuration.

Compare branch: https://github.com/Expensify/App/compare/main...wildan-m:App:wildan/93256-agent-avatar-maxheight?expand=1

What alternative solutions did you explore? (Optional)

Instead of relying on the shared EditAgentAvatarContent wrapper, the agent branch in ProfileAvatar could render EditAgentAvatarContent wrapped so the route matches the original screen's ScreenWrapper props. This is more invasive and duplicates wrapper configuration, whereas setting shouldEnableMaxHeight directly on the component's existing ScreenWrapper fixes both entry points with a single, minimal change.

[x-dev90]

Proposal

What is the root cause of that problem?

settings/profile/avatar is an RHP/modal route under the Profile settings screen, as shown in SETTINGS_TO_RHP:

App/src/libs/Navigation/linkingConfig/RELATIONS/SETTINGS_TO_RHP.ts

Lines 5 to 10 in 1ce07c3

	const SETTINGS_TO_RHP: Partial<Record<keyof SettingsSplitNavigatorParamList, string[]>> = {
	[SCREENS.SETTINGS.PROFILE.ROOT]: [
	SCREENS.SETTINGS.PROFILE.DISPLAY_NAME,
	SCREENS.SETTINGS.PROFILE.CONTACT_METHODS,
	SCREENS.SETTINGS.PROFILE.AVATAR,
	SCREENS.SETTINGS.PROFILE.CONTACT_METHOD_DETAILS,

For regular users, ProfileAvatar saves and exits that modal with Navigation.dismissModal(). For agent accounts, the same page renders EditAgentAvatarContent and only passes onSave, so save also dismisses the modal:

App/src/pages/settings/Profile/Avatar/AvatarPage.tsx

Lines 124 to 154 in 1ce07c3

	if (isAgentAccount) {
	const handleAgentSave = (params: OnSaveParams) => {
	if ('file' in params) {
	updateAvatar(params.file, {
	avatar: currentUserPersonalDetails?.avatar,
	avatarThumbnail: currentUserPersonalDetails?.avatarThumbnail,
	accountID: currentUserPersonalDetails?.accountID,
	});
	} else {
	const {customExpensifyAvatarID} = params;
	const uri = AGENT_AVATARS.resolveURI(customExpensifyAvatarID);
	updateAvatar(
	{
	uri,
	name: customExpensifyAvatarID,
	customExpensifyAvatarID,
	},
	{
	avatar: currentUserPersonalDetails?.avatar,
	avatarThumbnail: currentUserPersonalDetails?.avatarThumbnail,
	accountID: currentUserPersonalDetails?.accountID,
	},
	);
	}
	Navigation.dismissModal();
	};
	return (
	<EditAgentAvatarContent
	accountID={currentUserPersonalDetails.accountID}
	onSave={handleAgentSave}
	/>

The back button does not use that modal-dismiss path. EditAgentAvatarContent hard-codes the header back action to Navigation.goBack(fallbackRoute):

App/src/pages/settings/Agents/Fields/EditAgentAvatarPage.tsx

Lines 155 to 158 in 1ce07c3

	<HeaderWithBackButton
	title={translate('editAgentAvatarPage.title')}
	onBackButtonPress={() => Navigation.goBack(fallbackRoute)}
	/>

When EditAgentAvatarContent is used from the Profile avatar route, no fallbackRoute is passed:

App/src/pages/settings/Profile/Avatar/AvatarPage.tsx

Lines 150 to 154 in 1ce07c3

	return (
	<EditAgentAvatarContent
	accountID={currentUserPersonalDetails.accountID}
	onSave={handleAgentSave}
	/>

So pressing Back calls the generic Navigation.goBack() path, which dispatches navigationRef.current?.goBack() when there is no fallback route:

App/src/libs/Navigation/Navigation.ts

Lines 511 to 534 in 1ce07c3

	function goBack(backToRoute?: Route, options?: GoBackOptions) {
	clearSelectedText();
	if (!canNavigate('goBack', {backToRoute})) {
	return;
	}
	const runImmediately = !options?.waitForTransition;
	TransitionTracker.runAfterTransitions({
	callback: () => {
	if (!backToRoute && !shouldPopToSidebar && !navigationRef.current?.canGoBack()) {
	Log.hmmm('[Navigation] Unable to go back');
	return;
	}
	popAndRealignMfaMarker(
	() => {
	if (backToRoute) {
	goUp(backToRoute, options);
	} else if (shouldPopToSidebar) {
	popToSidebar();
	} else {
	navigationRef.current?.goBack();
	}

That is the wrong close primitive for this single-screen Profile avatar modal. The expected close primitive is Navigation.dismissModal(), which dispatches DISMISS_MODAL directly:

App/src/libs/Navigation/Navigation.ts

Lines 823 to 829 in 1ce07c3

	function dismissModal({ref = navigationRef, afterTransition, waitForTransition}: {ref?: NavigationRef; afterTransition?: () => void; waitForTransition?: boolean} = {}) {
	clearSelectedTextIfComposerBlurred();
	const runImmediately = !waitForTransition;
	const performDismiss = () => {
	TransitionTracker.runAfterTransitions({
	callback: () => {
	ref.dispatch({type: CONST.NAVIGATION.ACTION_TYPE.DISMISS_MODAL});

On iOS, the generic back pop briefly exposes the empty modal transition state before the Profile screen is visible again, which is the blank screen seen after pressing Back.

What changes do you think we should make in order to solve the problem?

Let EditAgentAvatarContent accept an optional caller-provided onBackButtonPress.

Then:

• Keep the current default behavior for Settings > Agents add/edit avatar flows by falling back to Navigation.goBack(fallbackRoute).
• Pass onBackButtonPress={() => Navigation.dismissModal()} from ProfileAvatar when the current account is an agent.
• Keep the existing agent save behavior unchanged, since it already uses Navigation.dismissModal() from the Profile avatar route.

Tests that should be added:

• Add/update a component test for ProfileAvatar with an agent session, press the header back button, and verify Navigation.dismissModal is called.
• Add/update coverage for the standalone EditAgentAvatarContent usage to verify the default back behavior still calls Navigation.goBack(fallbackRoute) when no custom back handler is provided.

I considered passing fallbackRoute={ROUTES.SETTINGS_PROFILE} from ProfileAvatar, but that still uses the generic goBack/goUp path for a modal route. The root-cause fix is to let the Profile avatar caller close its RHP/modal with the same dismissModal behavior it already uses on save.

What alternative solutions did you explore? (Optional)