[Due for payment 2026-07-23] Profile - Modify User Avatar save button is disabled when remove photo offline

[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.27-1
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/test-runs/TR-53253/folder/13177019/41237778/1539812357?sort=%2Bidentifier
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Windows 11
App Component: Other

Action Performed:

1. Go to Profile with Avatar
2. Disabled the internet connection
3. Go back to profile and remove the photo
4. Click Save

Expected Result:

Avatar should go back to default and save button should be enable

Actual Result:

Save button is disabled and avatar is not in default image

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7199057_1783133471120.s21.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7199057

Issue Owner

Current Issue Owner: @shubham1206agra

[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/3b89ce68e5c9e0aded2bf63136af5b2b50f9bce32705ed7c940b309d2898e191

[melvin-bot]

Triggered auto assignment to @inimaga (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[MelvinBot]

Proposal

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

When a user removes their profile photo while offline, the Save button stays disabled and the avatar preview does not fall back to the default image. This is a regression: reproducible in staging (v9.4.27-1) but not production.

What is the root cause of that problem?

A regression from #94567 ("[No QA] Support Dual-Initial Avatars in App", merged 2026-07-02, matching the staging-not-production timing). Commit 8d5b043 rewrote the remove-photo handler onImageRemoved to call deleteAvatar() and clear selected to undefined:

AvatarPreview.tsx:117-121

The Save button's enabled state is derived purely from:

EditUserAvatarContent.tsx:47 — const isDirty = imageData.uri !== '' || !!selected; — which gates the button at EditUserAvatarContent.tsx:194 (isDisabled={!isDirty}).

Because onImageRemoved now sets selected = undefined and empties imageData, isDirty becomes false → Save is disabled. Before the PR, onImageRemoved set selected to the default-avatar name, which kept isDirty true (Save enabled) and also drove the preview to render the default avatar via AvatarPreview.tsx:74-83. With selected now undefined, the preview falls through to currentUserPersonalDetails?.avatar instead of the default → avatar does not show default.

Diff that introduced the regression (from commit 8d5b043)

 const onImageRemoved = () => {
-    setSelected(
-        getDefaultAvatarName({
-            accountID: currentUserPersonalDetails?.accountID,
-            accountEmail: currentUserPersonalDetails?.email,
-        }),
-    );
+    deleteAvatar(currentUserPersonalDetails);
+    setSelected(undefined);
     setImageData({...EMPTY_FILE});
 };

The new flow fires deleteAvatar() immediately on removal instead of deferring the deletion to Save, and clears selected — leaving nothing to make the form "dirty" and no default value driving the preview.

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

As this is a deploy blocker, the safest option is to revert #94567 (or just its onImageRemoved change) so removal again sets selected to the default-avatar name, restoring both the enabled Save button and the default preview.

If a targeted forward fix is preferred, restore a "dirty on removal" signal so removal keeps the form dirty and the preview shows the default avatar — e.g. set selected to the default-avatar name (pre-PR behavior) rather than undefined, or add an explicit isRemoved flag feeding isDirty and the preview fallback. Whichever is chosen, verify the full offline path (queued DELETE_USER_AVATAR write + optimistic default avatar) still shows the default and re-enables Save.

What alternative solutions did you explore? (Optional)

N/A

---

Confidence: High — the disabled-Save root cause and its origin (PR #94567 / commit 8d5b043) are code-certain and match the staging-not-production timing.

Possibly related: #92793 (avatar discard-changes modal) — adjacent avatar-edit flow, different symptom, not a duplicate.

---

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