Distance new - Waypoints selection not working properly when tabbing via keyboard navigation

[lanitochka17]

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.3.2-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: Exploratory around #79420
Email or phone of affected tester (no customers): kiatest.78+ck11326@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Windows 11/Chrome
App Component: Money Requests

Action Performed:

Precondition : User has searched for few location while creating track distance & recent destinations is listed

1. Navigate to staging.new.expensify.com
2. Click FAB
3. Tab to the "Track distance" menu item and press Enter to open the popup
4. Tab to the Start waypoint >> Enter
5. Tab to the any location listed & press enter
6. Observe user navigated back to track distance flow but the waypoints are not selected
7. Tab again to Start point & press enter
8. Enter new waypoint
9. Tab to any location listed & press enter
10. Verify error appears
11. Tab again to location listed & press enter
12. Observe the waypoint now get selected & user navigated back

Expected Result:

On step 6 - User should be able to select waypoints in recent destinations list when tabbing via keyboard
On step 10 - Error should not appear when user enters new waypoint & try selecting the waypoint via tabbing. Waypoint should get selected on first attempt itself

Actual Result:

On step 6 - User cannot select waypoints in recent destinations list when tabbing via keyboard . User get redirected back to track distance flow but empty field is displayed without any selection
On step 10 - Error appears when user enters new waypoint & try selecting the waypoint via tabbing on first attempt. Waypoint get selected only on second attempt

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7049497_1768432526808.469.mp4

View all open jobs on GitHub

[melvin-bot]

Triggered auto assignment to @sonialiap (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[MobileMage]

Proposal

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

Keyboard navigation doesn't work for selecting waypoints in Track Distance flow. Tabbing to a recent destination and pressing Space fails to select it.

What is the root cause of that problem?

The react-native-google-places-autocomplete library's row Pressable elements aren't keyboard-focusable - they lack tabIndex={0}.

When you Tab from the text input, focus leaves the input triggering onBlur in AddressSearch. The blur handler at line 414-421 checks if relatedTarget is inside the container via isCurrentTargetInsideContainer. Since row Pressables aren't focusable, focus jumps outside the container, the check returns false, and setIsFocused(false) applies styles.h0 (height: 0) to the list - hiding it before the row's onPress can fire.

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

Add tabIndex={0}, accessible, role="button", and an onKeyDown handler to the row Pressable in the library via a patch at line 718.

This makes rows keyboard-focusable. When Tabbing from the input, focus moves to a row (inside the container), isCurrentTargetInsideContainer returns true, and the list stays visible. The onKeyDown handler triggers selection on Space.

What alternative solutions did you explore? (Optional)

Could modify AddressSearch to delay hiding on blur, but that's a workaround. The proper fix is making the rows focusable - standard web accessibility.

[duckemiah]

Proposal

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

Waypoint selection via keyboard doesn't work properly:

1. Tabbing to a recent destination and pressing Enter navigates back with empty field
2. Typing a new waypoint and tabbing to select it shows an error on first attempt

What is the root cause of that problem?

The react-native-google-places-autocomplete library's Pressable rows lack keyboard accessibility. Looking at _renderRow in the library:

<Pressable
  style={({ hovered, pressed }) => [...]}
  onPress={() => _onPress(rowData)}
  onBlur={_onBlur}
>

There's no tabIndex, no role, and no keyboard event handling. This means the rows aren't focusable via keyboard at all.

When the user tabs away from the input field, the blur handler in src/components/AddressSearch/index.tsx fires:

onBlur: (event) => {
    if (!isCurrentTargetInsideContainer(event, containerRef)) {
        setIsFocused(false);  // Hides the list
    }
},

Without a proper tabIndex on the list items, relatedTarget isn't recognized as being inside the container, so isFocused becomes false and the list disappears before any selection can happen.

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

Add a patch to react-native-google-places-autocomplete that makes the rows keyboard accessible.

I tested this incrementally and found each piece is necessary:

1. tabIndex={0} - Makes items focusable. Without this, Tab skips over them entirely.

2. role="button" - This was the tricky one. With just tabIndex and an onKeyDown handler, Space key worked but Enter didn't. The Enter key was being captured by the parent form and triggering submission instead of our handler. Adding role="button" tells the browser "this is a button" so Enter activates it properly.

3. stopPropagation() - Even with role="button", we need to stop the event from bubbling to prevent any form submission behavior.

Here's the full patch:

diff --git a/node_modules/react-native-google-places-autocomplete/GooglePlacesAutocomplete.js b/node_modules/react-native-google-places-autocomplete/GooglePlacesAutocomplete.js
index f733e49..b2c4d5e 100644
--- a/node_modules/react-native-google-places-autocomplete/GooglePlacesAutocomplete.js
+++ b/node_modules/react-native-google-places-autocomplete/GooglePlacesAutocomplete.js
@@ -718,6 +718,15 @@ export const GooglePlacesAutocomplete = ({ ref, ...rest }) => {
           ]}
           onPress={() => _onPress(rowData)}
           onBlur={_onBlur}
+          tabIndex={0}
+          accessible
+          role="button"
+          onKeyDown={(e) => {
+            if (e.key === 'Enter' || e.key === ' ') {
+              e.preventDefault();
+              e.stopPropagation();
+              _onPress(rowData);
+            }
+          }}
         >
           <View
             style={[

What alternative solutions did you explore? (Optional)

I first tried just tabIndex={0} thinking that would be enough, but Enter key still didn't work - the form was intercepting it. Adding role="button" fixed that. Could also modify the form behavior in AddressSearch, but patching the library is cleaner and improves accessibility at the source.

[bernhardoj]

Proposal

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

Can't select waypoint with keyboard.

What is the root cause of that problem?

The waypoint page itself is wrapped with FormProvider which by defaults enable press on enter. The enter is captured by the form keyboard shortcut, so the waypoint item can't be selected.

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

We can update validateSubmitShortcut to ignore the shortcut if the target is a pressable.

eventTarget.dataset['element'] === 'Pressable'

[Eskalifer1]

Proposal

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

Distance new - Waypoints selection not working properly when tabbing via keyboard navigation

What is the root cause of that problem?

Each form has props disablePressOnEnter set to false by default. This means that pressing Enter will always submit the form, even if the selected element is a list item.

And the validateSubmitShortcut function does not check this specific element:

App/src/components/Button/validateSubmitShortcut/index.ts

Lines 13 to 26 in 0860dcf

	const validateSubmitShortcut: ValidateSubmitShortcut = (isDisabled, isLoading, event) => {
	const eventTarget = event?.target as HTMLInputElement;
	if (
	isDisabled ||
	isLoading ||
	eventTarget.nodeName === CONST.ELEMENT_NAME.TEXTAREA ||
	(eventTarget.nodeName === CONST.ELEMENT_NAME.INPUT && eventTarget.autocomplete === 'one-time-code') ||
	(eventTarget?.contentEditable === 'true' && eventTarget.ariaMultiLine)
	) {
	return false;
	}
	event?.preventDefault();
	return true;
	};

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

There are several ways to solve this problem. I will choose one main solution and two alternative ones:

1. We need to add a check to the validateSubmitShortcut function. Since this element has specific data attributes, we can use them to identify that it is an Address Search element:
   

   App/src/components/Button/validateSubmitShortcut/index.ts

   Lines 13 to 26 in 0860dcf

   	const validateSubmitShortcut: ValidateSubmitShortcut = (isDisabled, isLoading, event) => {
   	const eventTarget = event?.target as HTMLInputElement;
   	if (
   	isDisabled ||
   	isLoading ||
   	eventTarget.nodeName === CONST.ELEMENT_NAME.TEXTAREA ||
   	(eventTarget.nodeName === CONST.ELEMENT_NAME.INPUT && eventTarget.autocomplete === 'one-time-code') ||
   	(eventTarget?.contentEditable === 'true' && eventTarget.ariaMultiLine)
   	) {
   	return false;
   	}
   	event?.preventDefault();
   	return true;
   	};

    if (
        eventTarget?.dataset?.['element'] === 'Pressable' &&
        typeof eventTarget?.dataset?.['sourceFile'] === 'string' &&
        eventTarget?.dataset?.['sourceFile'].includes('GooglePlacesAutocomplete')
    ) {
        return false;
    }

I think we can't just add a check for eventTarget.dataset[‘element’] === ‘Pressable’ here, as suggested above, because it will affect the entire project and most likely add new regressions, since we have Pressable elements in many parts of the project and in many places this functionality may not need to be disabled.

What alternative solutions did you explore? (Optional)

2. We can add a specific data attribute to the container here (dynamically, if necessary):
   

   App/src/components/AddressSearch/index.tsx

   Lines 359 to 363 in 0860dcf

   	<View
   	style={styles.w100}
   	ref={containerRef}
   	fsClass={forwardedFSClass}
   	>

Then update the validateSubmitShortcut function to check this date attribute, and if it exists, return false

3. We can use the disablePressOnEnter props, which will control whether the form can be submitted when pressing enter here:
   

   App/src/pages/iou/request/step/IOURequestStepWaypoint.tsx

   Lines 231 to 242 in 0860dcf

   	<FormProvider
   	style={[styles.flexGrow1, styles.mh5]}
   	formID={ONYXKEYS.FORMS.WAYPOINT_FORM}
   	enabledWhenOffline
   	validate={validate}
   	onSubmit={submit}
   	shouldValidateOnChange={false}
   	shouldValidateOnBlur={false}
   	submitButtonText={translate('common.save')}
   	shouldHideFixErrorsAlert
   	onScroll={onScroll}
   	>

const [disableOnPressEnter, setDisableOnPressEnter] = useState(false);


disablePressOnEnter={disableOnPressEnter}

Then pass 2 additional callbacks:

                            onFocus={() => {
                                setDisableOnPressEnter(true);
                            }}
                            onContainerBlur={() => {
                                setDisableOnPressEnter(false);
                            }}

We need to add a new prop onContainerBlur (or you can name it something else) that will be executed here (just onBlur is not suitable):

App/src/components/AddressSearch/index.tsx

Lines 415 to 419 in 0860dcf

	if (!isCurrentTargetInsideContainer(event, containerRef)) {
	setDisplayListViewBorder(false);
	setIsFocused(false);
	setIsTyping(false);
	}

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.