Web - Taxes - Trying to save new tax rate using enter on keyboard, reopens "Value" field.

[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: 9.3.91-4
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-37246/folder/13176868/41237324/1455622574
Email or phone of affected tester (no customers): ibellicotest+2723@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Windows 11 / Chrome
App Component: Workspace Settings

Action Performed:

Prerequisite: Account has at least one workspace.
Prerequisite 2: "Taxes" enabled.

1. Open the staging.new.expensify.com website.
2. Navigate to "Workspaces" > "Taxes"
3. Click on "Add Rate"
4. Enter a name and save it.
5. Enter a value and save it.
6. Press "Enter" on keyboard to save the new tax rate.
7. Note that "Value" field is reopened.

Expected Result:

Pressing enter after adding a name and value for a new tax rate, should save the changes and close RHP.

Actual Result:

While creating a new tax rate, pressing enter after adding a name and a value, redirects to "Value" field one more time.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7169782_1780420193469.Enter.mp4

View all open jobs on GitHub

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

[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/e1cb8bdb3d51d7535415934f2acca6da44b2a9b46635e720c512770fb2f3f5f0

[melvin-bot]

Triggered auto assignment to @marcochavezf (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 creating a new tax rate, after entering a Name and a Value, pressing Enter on the create page reopens the Value sub‑page instead of submitting the form and closing the RHP.

What is the root cause of that problem?

This is a regression from PR #90346 – "Migrate AmountSelectorModal to be nav RHP" (merged 2026‑06‑01, part of the 9.3.91 staging deploy). That PR changed the Value entry from an in‑place modal to a navigable RHP sub‑page.

The Value field is now a MenuItem (role="button") that calls Navigation.navigate(...). After you save the value and goBack() to the create page, the browser restores DOM focus to that Value MenuItem. The form's "Save" button only submits on Enter when no interactive element is focused — so the focused Value MenuItem disables the form shortcut, and Enter instead activates the focused button, re‑navigating to the Value page.

This is why the Name field (still a modal, not a navigation) does not exhibit the bug — only the migrated Value field does.

Code evidence

• Value field navigates to a sub‑page: TaxValuePicker.tsx:42-45
• Form submit's Enter shortcut is disabled when a focused element has an interactive role: Button/index.tsx:210 and Button/index.tsx:224 (isActive: pressOnEnter && !shouldDisableEnterShortcut && (isFocused || isPressOnEnterActive))
• shouldDisableEnterShortcut reads the DOM document.activeElement role via useActiveElementRole — true when the focused element's role is in Object.values(CONST.ROLE) and ≠ PRESENTATION
• MenuItem defaults to role="button": MenuItem.tsx:604
• Contrast: Name field opens a modal in place (no navigation, no focus restoration issue): TextPicker/index.tsx:34-39

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

Because this is a time‑sensitive deploy blocker, the safest action is to revert PR #90346, which restores the modal‑based Value entry that had no focus regression.

If a fix‑forward is preferred, ensure DOM focus is not left on the Value MenuItem after returning from the Value sub‑page (e.g. blur the active element / move focus off the menu item on goBack), so the form's Enter‑to‑submit shortcut becomes active again.

What alternative solutions did you explore?

Re‑doing the migration as a @react-navigation modal screen (already tracked in #91583) rather than an RHP push would avoid the focus‑restoration behavior, but that is larger than a deploy‑blocker fix.

Confidence: Medium‑High. The regression PR and the Enter‑shortcut mechanism are confirmed in code. The one unverified step is the browser restoring focus to the Value MenuItem after goBack() — the natural and standard web behavior, and consistent with the Name (modal) field being unaffected.

Related issue

• [$250] Migrate AmountSelectorModal to @react-navigation modal screen #91583 — "[$250] Migrate AmountSelectorModal to @react-navigation modal screen" (follow‑up to the same migration that caused this regression)

---

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