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-10-30] Expense - Submit button on the floating menu is not responsive after switching to table view #103392
Version Number: 9.5.5-0 Reproducible in staging?: Yes Reproducible in production?: N/A - new feature, doesn't exist in prod If this was caught during regression testing, add the test name, ID and link from BrowserStack:#103121 Email or phone of affected tester (no customers):[email protected] Issue reported by: Applause Internal Team Bug source: Exploratory - Significant User Experience Deterioration Device used: Mac 26.5 / Chrome App Component: Money Requests
Action Performed:
Precondition:
Complete onboarding with Submit to my employer to create a Submit workspace.
Go to staging.new.expensify.com
Go to workspace chat.
Create an expense.
Open the report.
Click More > Switch to table view.
Bulk select the expense.
Click Submit on the floating menu.
Expected Result:
Submit button on the floating menu will be responsive.
Actual Result:
Submit button on the floating menu is not responsive after switching to table view.
👋 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.
Root cause: On a Submit workspace, the bulk-action Submit button calls the submit-to popover opener. SelectionToolbar has no popover provider above it, so it gets the default opener, which does nothing. The click is silently ignored.
Recommendation: roll forward with a small fix. Revert the PR if the fix can't land quickly.
Render <SelectionToolbar> inside a ReportSubmitToPopoverRoot from SelectionToolbarGate. Then useLifecycleActions gets a real opener.
Wrap both SelectionBulkActionBar (wide layout) and SelectionDropdown (narrow layout) in a measurable submit-to anchor. This replaces the anchor at line 270.
Add a test: on a Submit workspace with one expense in table view, select the expense, press bulk Submit, and check that the submit-to popover opens.
The anchor at line 270 is rendered inside SelectionToolbar, so it can't provide context to a hook in that same component. The wide floating bar (index.tsx:296-308) has no anchor at all.
SubmitPrimaryAction and MoneyReportHeaderSecondaryActions already use the correct pattern: the provider sits in an outer component and the hook runs in an inner one.
Why the PR exposed it
On a Submit workspace, bulk Submit appears only when every selectable expense is selected, and it is blocked when more than one expense is selected. So it only appears on reports with exactly one selectable expense.
Before this PR, single-expense reports never showed table view or its selection bar.
The PR added shouldUseTableViewForSingleExpense to shouldDisplayReportTableView (MoneyRequestReportUtils.ts:172-176), which opened this path.
Other PRs in the deploy: None are involved. The files on this code path are identical between production 9.5.4-3 and staging 9.5.5-0-staging.
Why roll forward instead of revert: A revert removes the new path but leaves a rare production case broken: a 2-expense report where one expense is pending delete or has a reject error. The fix covers both cases.
Confidence: High, from reading the code. I did not reproduce it in the app.
changed the title [-]Expense - Submit button on the floating menu is not responsive after switching to table view[/-][+][Due for payment 2026-10-30] Expense - Submit button on the floating menu is not responsive after switching to table view[/+]on Oct 23, 2026
The solution for this issue has been 🚀 deployed to production 🚀 in version 9.5.18-1 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-10-30. 🎊
The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the Contributor+ 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]. If no checklist is needed for this issue, you can click: [no checklist button]
Activity
applause-bot commentedon Oct 7, 2026
While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/969055ad74ca284a6552b8440099ed88ff58d2bf4af7e30d68da737c5a176199
melvin-bot commentedon Oct 7, 2026
You have been assigned to this deploy blocker because you recently merged this PR: #103121
melvin-bot commentedon Oct 7, 2026
@Beamanator @daledah you have been assigned to this deploy blocker because you reviewed the offending PR: #103121
github-actions commentedon Oct 7, 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:
melvin-bot commentedon Oct 7, 2026
💬 A slack conversation has been started in #expensify-open-source
MelvinBot commentedon Oct 7, 2026
Deploy Blocker Analysis
Causing PR: Add a More menu option to switch single-expense reports between expense view and table view (
Expensify/App#103121). It made the bug reachable. The faulty code was already in production.Root cause: On a Submit workspace, the bulk-action Submit button calls the submit-to popover opener.
SelectionToolbarhas no popover provider above it, so it gets the default opener, which does nothing. The click is silently ignored.Recommendation: roll forward with a small fix. Revert the PR if the fix can't land quickly.
Fix in
SelectionToolbar/index.tsx:<SelectionToolbar>inside aReportSubmitToPopoverRootfromSelectionToolbarGate. ThenuseLifecycleActionsgets a real opener.SelectionBulkActionBar(wide layout) andSelectionDropdown(narrow layout) in a measurable submit-to anchor. This replaces the anchor at line 270.Investigation details
How the click ends in a no-op
handleSubmitReportopens the submit-to popover instead of submitting directly (useLifecycleActions.tsx:303). The opener comes from context atuseLifecycleActions.tsx:92.ReportSubmitToPopoverAnchor.tsx:21-23).SelectionToolbarreads the context throughuseSelectionModeReportActions(index.tsx:194), which callsuseLifecycleActions(useSelectionModeReportActions.ts:100).SelectionToolbar, so it can't provide context to a hook in that same component. The wide floating bar (index.tsx:296-308) has no anchor at all.SubmitPrimaryActionandMoneyReportHeaderSecondaryActionsalready use the correct pattern: the provider sits in an outer component and the hook runs in an inner one.Why the PR exposed it
shouldUseTableViewForSingleExpensetoshouldDisplayReportTableView(MoneyRequestReportUtils.ts:172-176), which opened this path.Other PRs in the deploy: None are involved. The files on this code path are identical between production
9.5.4-3and staging9.5.5-0-staging.Why roll forward instead of revert: A revert removes the new path but leaves a rare production case broken: a 2-expense report where one expense is pending delete or has a reject error. The fix covers both cases.
Confidence: High, from reading the code. I did not reproduce it in the app.
view run
melvin-bot commentedon Oct 7, 2026
If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.
If a regression has occurred and you are the assigned CM follow the instructions here.
If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.
melvin-bot commentedon Oct 7, 2026
If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.
If a regression has occurred and you are the assigned CM follow the instructions here.
If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.
19 remaining items
melvin-bot commentedon Oct 21, 2026
If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.
If a regression has occurred and you are the assigned CM follow the instructions here.
If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.
mitarachim commentedon Oct 21, 2026
Deploy Blocker #104657 was identified to be related to the PR #103703 that attempted to fix this issue.
melvin-bot commentedon Oct 21, 2026
If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.
If a regression has occurred and you are the assigned CM follow the instructions here.
If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.
melvin-bot commentedon Oct 22, 2026
If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.
If a regression has occurred and you are the assigned CM follow the instructions here.
If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.
jponikarchuk commentedon Oct 22, 2026
Deploy Blocker #104676 was identified to be related to the PR #103703 that attempted to fix this issue.
jponikarchuk commentedon Oct 22, 2026
Deploy Blocker #104678 was identified to be related to the PR #103703 that attempted to fix this issue.
jponikarchuk commentedon Oct 22, 2026
Deploy Blocker #104681 was identified to be related to the PR #103703 that attempted to fix this issue.
melvin-bot commentedon Oct 22, 2026
If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.
If a regression has occurred and you are the assigned CM follow the instructions here.
If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.
jponikarchuk commentedon Oct 22, 2026
Deploy Blocker #104682 was identified to be related to the PR #103703 that attempted to fix this issue.
melvin-bot commentedon Oct 22, 2026
If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.
If a regression has occurred and you are the assigned CM follow the instructions here.
If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.
[-]Expense - Submit button on the floating menu is not responsive after switching to table view[/-][+][Due for payment 2026-10-30] Expense - Submit button on the floating menu is not responsive after switching to table view[/+]melvin-bot commentedon Oct 23, 2026
@daledah
The solution for this issue has been 🚀 deployed to production 🚀 in version 9.5.18-1 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-10-30. 🎊
The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the Contributor+ 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]. If no checklist is needed for this issue, you can click: [no checklist button]