[$250] Pressing Enter key does not open the Confirm Details page when adding workspace members

[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.99-8
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/folder/13177080/test-cases/41237955
Email or phone of affected tester (no customers): mnata.utest+0406aa@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Windows 11 / Chrome
App Component: Workspace Settings

Action Performed:

1. Navigate to Workspace > Members
2. Select multiple contacts
3. Focus Search field
4. Press the Enter key
5. Search for and select a new member
6. Press the Enter key again

Expected Result:

After step 3, The Confirm Details right-hand panel (RHP) should be displayed, allowing the user to review and confirm the member addition.

Actual Result:

Pressing the Enter key does not open the Confirm Details page/RHP. After step 5 Confirm details RHP displayed

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7172638_1780664967913.Recording__2964.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Svetlana Lazutkina
Bug ID: 7172638

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022062965600589688928
• Upwork Job ID: 2062965600589688928
• Last Price Increase: 2026-06-12

[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/5e81f7e37be469e199bf68919da3072a85320bd79f06efe0eaffd65ff765159a

[MelvinBot]

Issue Analysis

Root cause (high confidence): When you select members by mouse click, the SelectionList moves its internal focusedIndex onto the clicked row, but does not set isKeyboardNavigating. Pressing Enter then hits the list's Enter shortcut, which is wired to toggle the focused row (not to confirm) and swallows the event — so the "Next" button never fires and the Confirm Details RHP never opens. The second Enter works only because by then focusedIndex has been reset to -1, letting Enter bubble to the submit button.

Proposal

What is the root cause of that problem?

The page renders SelectionListWithSections with shouldUpdateFocusedIndex, a confirmButtonOptions.onConfirm (→ inviteUser, which navigates to Confirm Details), and a footer FormAlertWithSubmitButton that uses pressOnEnter.

Two things collide on Enter:

1. Clicking a contact calls selectRow(item, clickedIndex), which — because shouldUpdateFocusedIndex is set — moves focusedIndex onto the clicked row. A mouse click does not set isKeyboardNavigating, so the row is "focused" internally but not visually highlighted.
2. The list's Enter shortcut is selectFocusedItem (it toggles the focused row), gated by isActive: focusedIndex >= 0. Plain Enter is wired to onConfirm only via Ctrl+Enter, never plain Enter. Because a focused item exists, shouldBubble evaluates to false, so the handler runs the toggle and short-circuits the keyboard-shortcut stack — the footer "Next" button's pressOnEnter handler never gets the event.

Net effect: first Enter silently toggles an invisibly-focused row instead of confirming. The second Enter works because, after you search + select a new member and the search input clears, useSearchFocusSync resets focusedIndex to -1, which makes the list's Enter shortcut inactive so the event bubbles to the "Next" button.

The key inconsistency: the component already uses isKeyboardNavigating to decide whether a row is visually focused, but the Enter handler keys off the raw focusedIndex >= 0. So Enter acts on a row the user can't see as focused.

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

In BaseSelectionListWithSections.tsx, gate the plain-Enter row-selection on isKeyboardNavigating (the same signal already used for visual focus), not just focusedIndex >= 0. When the user hasn't keyboard-navigated — i.e., they mouse-clicked their selections and are sitting in the empty search box — Enter should bubble to the footer's submit button and trigger onConfirm / inviteUser. Concretely, require isKeyboardNavigating in the Enter useKeyboardShortcut isActive condition (and the corresponding shouldBubble) so mouse-click focus doesn't claim the Enter key.

Because this is the shared list component, verify that other multi-select screens which rely on arrow-navigate-then-Enter-to-toggle still behave correctly.

What alternative solutions did you explore? (Optional)

• Route plain Enter to confirmButtonOptions.onConfirm when items are already selected (mirroring Ctrl+Enter). Riskier — changes Enter semantics for every list using this component.
• Bump the footer button's enterKeyEventListenerPriority. Insufficient on its own: the list handler's shouldBubble: false still short-circuits the handler stack regardless of priority ordering.

Investigation details & code references

All refs at commit d77329e.

• BaseSelectionListWithSections.tsx:274-279 — Enter shortcut → selectFocusedItem; isActive: focusedIndex >= 0; shouldBubble: itemsCount > 0 && !getFocusedItem().
• BaseSelectionListWithSections.tsx:224-230 — selectFocusedItem only calls selectRow (toggles); it does not call onConfirm.
• BaseSelectionListWithSections.tsx:281-296 — Ctrl+Enter is the only handler that calls confirmButtonOptions.onConfirm.
• BaseSelectionListWithSections.tsx:201-222 — selectRow moves focusedIndex to the clicked row when shouldUpdateFocusedIndex.
• BaseSelectionListWithSections.tsx:96-113 — isKeyboardNavigating is set only via setHasKeyBeenPressed (arrow keys / Tab), not on mouse click.
• BaseSelectionListWithSections.tsx:387 — visual focus already keys off isKeyboardNavigating (the signal the Enter handler should also use).
• useSearchFocusSync.ts:64-108 — resets focusedIndex to -1 after the search input clears, which is why the second Enter bubbles to the submit button and works.
• DynamicWorkspaceInvitePage.tsx:260-278 — passes shouldUpdateFocusedIndex, confirmButtonOptions.onConfirm = inviteUser, and a footerContent button.
• FormAlertWithSubmitButton.tsx:111-151 — the "Next" button uses pressOnEnter (default priority 0); this is what should navigate to Confirm Details when Enter bubbles.

Keyboard-shortcut mechanics: Both the list's Enter handler and the button's pressOnEnter register at default priority 0. Because the button lives inside the list's footerContent, child effects run first, so the list's Enter handler ends up at the top of the stack and fires first. shouldBubble: false then short-circuits the handler loop, so the button's handler is skipped.

Likely additional symptom: the first Enter doesn't just "do nothing" — it toggles (deselects) the invisibly-focused contact. Worth confirming during repro.

Alternative explanations ruled out: This is a deterministic client-side keyboard-ordering bug (no backend/logs involved). It reproduces on web platforms (Windows/Chrome, macOS Chrome/Safari), consistent with pressOnEnter being active on web. The fix is entirely within the Expensify/App repo.

---

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

[yusufdeveloper2903]

Proposal

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

On the Workspace → Members → Invite page, after you’ve selected one or more members and the search field is focused (and empty), pressing Enter does nothing — it should submit the selection and open the Confirm Details RHP.

What is the root cause of that problem?

The invite page is DynamicWorkspaceInvitePage, which renders a SelectionListWithSections and wires the “Next” action through confirmButtonOptions.onConfirm:

https://github.com/Expensify/App/blob/2af5de8482a/src/pages/workspace/DynamicWorkspaceInvitePage.tsx#L269-L272

Inside the list, the Enter key on the search box is handled by the TextInput’s onSubmitEditing, which is bound to selectFocusedItem:

https://github.com/Expensify/App/blob/2af5de8482a/src/components/SelectionList/SelectionListWithSections/BaseSelectionListWithSections.tsx#L345

selectFocusedItem only ever toggles the currently focused row. If nothing is focused, it returns and does nothing:

https://github.com/Expensify/App/blob/2af5de8482a/src/components/SelectionList/SelectionListWithSections/BaseSelectionListWithSections.tsx#L224-L230

So everything hinges on focusedIndex. In the repro, focusedIndex is -1, and here’s why:

• The page never passes initiallyFocusedItemKey, so useFlattenedSections starts focus at -1 (useFlattenedSections.ts#L102).
• Selecting rows by clicking is treated as selectionChangedByClicking, so useSearchFocusSync deliberately leaves focus untouched.
• Crucially, when the search box is idle/empty (!prevSearchValue && !searchValue), useSearchFocusSync actively resets focus to -1:

https://github.com/Expensify/App/blob/2af5de8482a/src/components/SelectionList/hooks/useSearchFocusSync.ts#L95-L101

With focusedIndex === -1, pressing Enter goes nowhere:

1. The plain ENTER keyboard shortcut is gated by focusedIndex >= 0, so it’s inactive — BaseSelectionListWithSections.tsx#L274-L279.
2. The TextInput’s onSubmitEditing → selectFocusedItem → getFocusedItem() returns undefined → no-op.
3. The only path that calls onConfirm is the CTRL/CMD+ENTER shortcut — #L281-L296 — which a user pressing plain Enter never triggers.

That’s the bug: when there’s a valid selection but no focused row, Enter has no fallback to the confirm action. (As soon as you type a query, useSearchFocusSync sets focusedIndex to the first row, which is why Enter “starts working” later in the repro — it then has a row to act on.)

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

When selectFocusedItem runs with no focused row, fall back to the list’s own confirm action (the same onConfirm already wired to CTRL+ENTER). This is the only point that needs to change — it’s the shared handler for the search box’s onSubmitEditing, and the plain-ENTER shortcut is inactive in this state, so there’s no risk of double-firing.

     const selectFocusedItem = () => {
         const focusedItem = getFocusedItem();
         if (!focusedItem || focusedItem.isInteractive === false) {
+            // No row is focused (e.g. the search box is empty with items already selected).
+            // Fall back to the confirm action so Enter submits the selection instead of doing nothing.
+            if (!focusedItem && confirmButtonOptions?.onConfirm && !confirmButtonOptions?.isDisabled) {
+                confirmButtonOptions.onConfirm();
+            }
             return;
         }
         selectRow(focusedItem);
     };

Why this is correctly scoped:

• It only fires when no row is focused. The moment the user types a search term, useSearchFocusSync focuses the first row, so the existing “Enter selects the focused/highlighted option” behavior is fully preserved.
• It reuses the component’s own established pattern — onConfirm is already the confirm path for CTRL+ENTER (#L281-L296); we’re just letting plain Enter reach it when there’s nothing to select. So we don’t invent new behavior, we close a gap.
• The !confirmButtonOptions?.isDisabled guard means it does nothing when the selection is empty (matching the disabled “Next” button), and the confirmButtonOptions?.onConfirm guard means lists that don’t opt into a confirm action are completely unaffected.
• This lives in the shared SelectionListWithSections, so the same fix also covers the sibling invite/participant flows that share this exact pattern (e.g. RoomInvitePage, InviteReportParticipantsPage, NewChatPage, MoneyRequestAttendeeSelector), giving consistent Enter-to-confirm everywhere.

Edge cases / platforms: This is a web/desktop keyboard interaction (the issue repros on Windows/macOS Chrome & Safari); native is unaffected since there’s no hardware Enter flow there. Offline is fine — onConfirm/inviteUser is enabledWhenOffline and only sets the draft + navigates (DynamicWorkspaceInvitePage.tsx#L178-L193). The plain BaseSelectionList (non-sections) variant has the identical selectFocusedOption pattern (BaseSelectionList.tsx#L312-L317); if we want full parity we can apply the same one-liner there.

What alternative solutions did you explore? (Optional)

• Relax the ENTER keyboard shortcut’s isActive from focusedIndex >= 0 to also fire when confirm is enabled — rejected. On web, pressing Enter inside the search box already fires onSubmitEditing, so the shortcut and onSubmitEditing would both run and call onConfirm twice (double navigation). Keeping the fix in the single shared selectFocusedItem handler avoids that.
• Set an initiallyFocusedItemKey so a row is always focused — rejected. That doesn’t solve the problem: Enter on a focused row toggles that row’s selection, it still doesn’t open Confirm Details, and it would visually highlight a row the user didn’t intend to act on.
• Fix only in DynamicWorkspaceInvitePage (e.g. a custom onSubmit) — rejected. The gap is in the shared list behavior; fixing it at the component level resolves the whole class of invite/participant pages instead of patching one screen.

[MobileMage]

🚨 Edited by proposal-police: This proposal was edited at 2026-06-05 18:32:16 UTC.

Proposal

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

On DynamicWorkspaceInvitePage (Workspace > Members > Invite member), the user can preselect contacts by clicking their checkboxes. With the search input focused and at least one member selected, pressing Enter is expected to navigate to the Confirm Details RHP (the "Next" action) but does nothing. The Confirm Details panel only opens after the user performs a fresh search + select cycle (step 5 in the repro), at which point a subsequent Enter press becomes effective. This is a web-only bug — CTRL/CMD + Enter already works as an undocumented workaround.

What is the root cause of that problem?

DynamicWorkspaceInvitePage renders SelectionListWithSections and wires the "Next" action into confirmButtonOptions.onConfirm = inviteUser (the function that calls setWorkspaceInviteMembersDraft then Navigation.navigate(WORKSPACE_INVITE_MESSAGE)). Inside BaseSelectionListWithSections.tsx, two keyboard shortcuts are registered for Enter: a plain ENTER that calls selectFocusedItem (toggle the focused row) and a CTRL_ENTER that calls confirmButtonOptions.onConfirm. The plain ENTER shortcut is gated by focusedIndex >= 0 in its isActive condition, and its handler selectFocusedItem early-returns when no row is focused — so it has no path to call onConfirm. CTRL_ENTER correctly handles the "no focus" case via the confirmButtonOptions?.onConfirm branch.

useKeyboardShortcut(CONST.KEYBOARD_SHORTCUTS.ENTER, selectFocusedItem, {
    captureOnInputs: true,
    shouldBubble: itemsCount > 0 && !getFocusedItem(),
    shouldStopPropagation,
    isActive: !disableKeyboardShortcuts && isScreenFocused && focusedIndex >= 0 && !disableEnterShortcut,
});

App/src/components/SelectionList/SelectionListWithSections/BaseSelectionListWithSections.tsx

Lines 274 to 279 in d77329e

	useKeyboardShortcut(CONST.KEYBOARD_SHORTCUTS.ENTER, selectFocusedItem, {
	captureOnInputs: true,
	shouldBubble: itemsCount > 0 && !getFocusedItem(),
	shouldStopPropagation,
	isActive: !disableKeyboardShortcuts && isScreenFocused && focusedIndex >= 0 && !disableEnterShortcut,
	});

focusedIndex is driven by useSearchFocusSync. When the user opens the invite page with no active search and toggles selections by clicking, the hook sees prevSearchValue === searchValue === '' so isSearchIdle = true, and it forcibly resets focus to -1 after every selection change. The result: focusedIndex stays at -1, the ENTER shortcut is registered as inactive, and useKeyboardShortcut neither runs the handler nor calls preventDefault. The keypress then falls through to the input's onSubmitEditing (onSubmit={selectFocusedItem} on the <TextInput> inside SelectionList/components/TextInput.tsx), but selectFocusedItem itself early-returns because getFocusedItem() returns undefined. So both paths silently swallow the press.

const isSearchIdle = !prevSearchValue && !searchValue;
const shouldResetFocus = isSearchIdle || (selectedOptionsChanged && prevItemsLength === data.length);
if (shouldResetFocus) {
    setFocusedIndex(-1);
    return;
}

App/src/components/SelectionList/hooks/useSearchFocusSync.ts

Lines 95 to 101 in d77329e

	const isSearchIdle = !prevSearchValue && !searchValue;
	const shouldResetFocus = isSearchIdle || (selectedOptionsChanged && prevItemsLength === data.length);
	if (shouldResetFocus) {
	setFocusedIndex(-1);
	return;
	}

Step 5 unblocks the next Enter for a specific reason: typing a search term changes searchValue from '' to e.g. "jane", which exits the isSearchIdle branch. When the user clicks a result, selectRow clears the input (shouldClearInputOnSelect default), and useSearchFocusSync now hits the bottom branch (hasSearchBeenCleared is true but canSelectMultiple skips the early return), then setFocusedIndex(firstFocusableIndex), which is >= 0. With a focused row, the next Enter press passes the isActive gate — but it then toggles that focused row instead of confirming, which is also wrong. The user only reaches Confirm Details by then pressing Enter once more after setFocusedIndex lands on a non-selected item where toggling effectively adds it and triggers another sync. The behavior is non-deterministic from the user's perspective, but the underlying defect is the same: ENTER has no path to confirmButtonOptions.onConfirm.

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

Fix this at the choke point — selectFocusedItem — and expand the ENTER shortcut's isActive so it actually registers when there's no focused row but a confirm action is available. Routing the fallback through selectFocusedItem also covers the <TextInput>'s onSubmitEditing path (which calls the same function) without duplicating logic in two places. Below in BaseSelectionListWithSections.tsx:

const selectFocusedItem = (e?: GestureResponderEvent | KeyboardEvent) => {
    const focusedItem = getFocusedItem();
    if (!focusedItem || focusedItem.isInteractive === false) {
        // No focused row: when in multi-select with a primary confirm action available, treat Enter as "Next".
        if (canSelectMultiple && confirmButtonOptions?.onConfirm && !confirmButtonOptions?.isDisabled) {
            confirmButtonOptions.onConfirm(e, undefined);
        }
        return;
    }
    selectRow(focusedItem);
};

useKeyboardShortcut(CONST.KEYBOARD_SHORTCUTS.ENTER, selectFocusedItem, {
    captureOnInputs: true,
    shouldBubble: itemsCount > 0 && !getFocusedItem(),
    shouldStopPropagation,
    isActive:
        !disableKeyboardShortcuts &&
        isScreenFocused &&
        !disableEnterShortcut &&
        (focusedIndex >= 0 || (canSelectMultiple && !!confirmButtonOptions?.onConfirm && !confirmButtonOptions?.isDisabled)),
});

This is safe because the fallback is scoped to canSelectMultiple && confirmButtonOptions?.onConfirm && !confirmButtonOptions?.isDisabled — exactly the contract that CTRL_ENTER already honors. Single-select lists are unaffected (no canSelectMultiple), lists without a confirm button are unaffected (no onConfirm), and lists where the confirm action is disabled (e.g. zero selections) are unaffected (isDisabled blocks it). It also doesn't change the click/touch flow — selectRow is still the path for direct row interaction. The Enter-on-row toggling behavior when a row is focused is preserved verbatim.

App/src/components/SelectionList/SelectionListWithSections/BaseSelectionListWithSections.tsx

Lines 224 to 230 in d77329e

	const selectFocusedItem = () => {
	const focusedItem = getFocusedItem();
	if (!focusedItem || focusedItem.isInteractive === false) {
	return;
	}
	selectRow(focusedItem);
	};

What alternative solutions did you explore? (Optional)

An alternative is to change useSearchFocusSync so that the isSearchIdle branch doesn't reset focusedIndex to -1 when selections already exist — leaving the cursor on a sensible row so the existing ENTER shortcut stays active. Rejected because (a) it would change keyboard-cursor positioning across every consumer of SelectionListWithSections, not just invite flows, and (b) even with a focused row, Enter would still toggle that row rather than confirm — the user would have to figure out that the "Next" action requires the cursor to be on an already-selected row, which is a worse UX than just making Enter confirm directly.

[moxw]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[melvin-bot]

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

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022062965600589688928

[github-actions]

⚠️ @moxw Your proposal is a duplicate of an already existing proposal and has been automatically withdrawn to prevent spam. Please review the existing proposals before submitting a new one.