You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Due for payment 2026-03-30] Attachment - "No content to add" error is shown when uploading attachment #85671
Version Number: 9.3.40-0 Reproducible in staging?: Yes Reproducible in production?: No If this was caught during regression testing, add the test name, ID and link from BrowserStack:#70740 Email or phone of affected tester (no customers):sdjsdjosijnsodiosd@gmail.com Issue reported by: Applause Internal Team Bug source: Pull Request QA execution Device used: Mac 26.2 / Chrome App Component: Chat Report View
Action Performed:
Go to staging.new.expensify.com
Go to workspace chat.
Upload an attachment.
Expected Result:
Attachment will be uploaded.
Actual Result:
"No content to add" error is shown when uploading attachment.
👋 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:
Identify the pull request that introduced this issue and revert it.
Classification: Frontend bug Causing PR: #83299 - "FAB popover decomposition" by @TMisiukiewicz (High confidence) Related Issues: Duplicate of #85661
Recommendation: DUPLICATE
This issue is a duplicate of #85661. Both issues describe the identical bug with the same reproduction steps: "New report RHP opens and closes when creating second report."
The issue title mentions "Attachment - No content to add error" which appears to be incorrect. The actual bug described in the issue body matches #85661 exactly:
Both have identical reproduction steps (steps 1-9)
Both show the same symptom: "New report RHP opens and closes"
Both are reproducible in staging but NOT in production
Both use the same test account email
Verification
This is clearly a duplicate issue. The causing PR #83299 has been verified in #85661, which includes:
Detailed root cause analysis by @MelvinBot identifying the browser history race condition
Proposed fix: Set shouldHandleNavigationBack: false in useCreateEmptyReportConfirmation.tsx
Verification that the issue does not reproduce on main branch (only on staging)
Root Cause
Per the detailed analysis in #85661, the root cause is a browser history stack race condition introduced when PR #83299 migrated the empty-report confirmation from an inline <ConfirmModal> to the global modal system via useConfirmModal. The global modal system always sets shouldHandleNavigationBack: true, causing the FAB popover's deferred history.back() to inadvertently close the confirmation modal.
changed the title [-]Attachment - "No content to add" error is shown when uploading attachment[/-][+][Due for payment 2026-03-30] Attachment - "No content to add" error is shown when uploading attachment[/+]on Mar 23, 2026
The solution for this issue has been 🚀 deployed to production 🚀 in version 9.3.41-4 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:
@parasharrajat The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the BugZero Checklist from here into a new comment on this GH and complete it. If you have the K2 extension, you can simply click: [this button]
Activity
melvin-bot commentedon Mar 18, 2026
You have been assigned to this deploy blocker because you recently merged this PR: #83299
melvin-bot commentedon Mar 18, 2026
💬 A slack conversation has been started in #expensify-open-source
github-actions commentedon Mar 18, 2026
👋 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:
OSBotify commentedon Mar 18, 2026
🔍 Investigation Summary
Classification: Frontend bug
Causing PR: #83299 - "FAB popover decomposition" by @TMisiukiewicz (High confidence)
Related Issues: Duplicate of #85661
Recommendation: DUPLICATE
This issue is a duplicate of #85661. Both issues describe the identical bug with the same reproduction steps: "New report RHP opens and closes when creating second report."
The issue title mentions "Attachment - No content to add error" which appears to be incorrect. The actual bug described in the issue body matches #85661 exactly:
Labels: Keeping
DeployBlockerCashsince this is the same frontend bug as #85661, which is already being investigated and has a proposed fix.📋 Detailed Analysis
Evidence
Verification
This is clearly a duplicate issue. The causing PR #83299 has been verified in #85661, which includes:
shouldHandleNavigationBack: falseinuseCreateEmptyReportConfirmation.tsxRoot Cause
Per the detailed analysis in #85661, the root cause is a browser history stack race condition introduced when PR #83299 migrated the empty-report confirmation from an inline
<ConfirmModal>to the global modal system viauseConfirmModal. The global modal system always setsshouldHandleNavigationBack: true, causing the FAB popover's deferredhistory.back()to inadvertently close the confirmation modal.The fix is already being implemented in #85661.
aimane-chnaif commentedon Mar 18, 2026
@lanitochka17 can you please check issue description and video? It doesn't match with issue title.
12 remaining items
m-natarajan commentedon Mar 19, 2026
Passed, Chrome / v9.3.40-8
Screen.Recording.2026-03-19.at.15.58.47.mp4
cristipaval commentedon Mar 19, 2026
Thanks! Closing
[-]Attachment - "No content to add" error is shown when uploading attachment[/-][+][Due for payment 2026-03-30] Attachment - "No content to add" error is shown when uploading attachment[/+]melvin-bot commentedon Mar 23, 2026
Reviewinglabel has been removed, please complete the "BugZero Checklist".melvin-bot commentedon Mar 23, 2026
The solution for this issue has been 🚀 deployed to production 🚀 in version 9.3.41-4 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:
If no regressions arise, payment will be issued on 2026-03-30. 🎊
For reference, here are some details about the assignees on this issue:
melvin-bot commentedon Mar 23, 2026
@parasharrajat The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the BugZero Checklist from here into a new comment on this GH and complete it. If you have the K2 extension, you can simply click: [this button]
melvin-bot commentedon Mar 23, 2026
Triggered auto assignment to @mallenexpensify (
Awaiting Payment)