[HOLD for payment 2024-12-25] [$250] iOS Search - Filter icon is not responsive when navigating to Search via WS chat in WS settings

[vincdargento]

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.0.71-1
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught on HybridApp, is this reproducible on New Expensify Standalone?: Yes, reproducible on both
If this was caught during regression testing, add the test name, ID and link from TestRail: N/A
Email or phone of affected tester (no customers): applausetester+kh1311020@applause.expensifail.com
Issue reported by: Applause Internal Team

Action Performed:

1. Launch ND or hybrid app.
2. Go to workspace settings.
3. Tap on the workspace chat under "Submit expenses using your workspace chat below"
4. Tap on the search icon on the top right.
5. Type anything and search it.
6. On Search page, tap on the filter icon.

Expected Result:

Filter options will open.

Actual Result:

Filter icon is not responsive.

Workaround:

Unknown

Platforms:

• Android: Standalone
• Android: HybridApp
• Android: mWeb Chrome
• iOS: Standalone
• iOS: HybridApp
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

bug.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021864902077815200576
• Upwork Job ID: 1864902077815200576
• Last Price Increase: 2024-12-06
• Automatic offers:
• rayane-djouah | Reviewer | 105267754

Issue Owner

Current Issue Owner: @kadiealexander

[melvin-bot]

Triggered auto assignment to @kadiealexander (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.

[daledah]

Proposal

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

Filter icon is not responsive.

What is the root cause of that problem?

We are using normal navigate here

App/src/pages/workspace/WorkspaceInitialPage.tsx

Line 456 in 0e28aa4

onPress={() => Navigation.navigate(ROUTES.REPORT_WITH_ID.getRoute(currentUserPolicyExpenseChat?.reportID ?? '-1'))}

Search page is open on top of workspaceInitiaPage so canAccessRoute is incorrectly computed

App/src/pages/workspace/WorkspaceInitialPage.tsx

Lines 360 to 362 in 0e28aa4

	// We are checking if the user can access the route.
	// If user can't access the route, we are dismissing any modals that are open when the NotFound view is shown
	const canAccessRoute = activeRoute && menuItems.some((item) => item.routeName === activeRoute);

And we get dismiss all RHP modal in this useEffect

App/src/pages/workspace/WorkspaceInitialPage.tsx

Lines 372 to 375 in 0e28aa4

	// We are dismissing any modals that are open when the NotFound view is shown
	Navigation.isNavigationReady().then(() => {
	Navigation.closeRHPFlow();
	});

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

When workspace init is the only route in the navigator state. We can use navigate with a type of 'UP'

    onPress={() => Navigation.navigate(ROUTES.REPORT_WITH_ID.getRoute(currentUserPolicyExpenseChat?.reportID ?? '-1'), 'UP')}

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

NA

What alternative solutions did you explore? (Optional)

We can use function closeAndNavigate here

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.

[saifelance]

Proposal

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

The issue involves [specific problem, e.g., "inconsistent form behavior causing incorrect submissions"], affecting [impact, e.g., "data reliability and user experience"].

What is the root cause of that problem?

Triggered by [root cause, e.g., "a race condition in asynchronous state management"].

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

1. Refactor state management to handle async operations correctly.
2. Add validation checks at client/server levels.
3. Enhance error handling for better feedback and logging.
4. Update outdated dependencies.

Suggested Fix for the Filter Icon Handler

function onFilterIconPress() {
    if (isExecuting) {
        return; // Prevent multiple executions.
    }

    singleExecution(() => {
        // Logic to show filter options
        Navigation.navigate(ROUTES.SEARCH_FILTER); // Adjust as per your route setup.
    })();
}

Add Accessibility and Clickability Checks

<TouchableOpacity
    onPress={onFilterIconPress}
    accessible={true}
    accessibilityLabel={translate('search.filter')}
    style={styles.filterIconContainer}
>
    <Expensicons.Filter />
</TouchableOpacity>

What alternative solutions did you explore? (Optional)

1. Rewrite module (time-intensive).
2. Adopt a new state library (steep learning curve).
3. Implementing targeted fixes and robust tests will resolve the issue and prevent recurrence.

[melvin-bot]

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

[melvin-bot]

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

[bernhardoj]

Proposal

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

The filter button is "unresponsive"

What is the root cause of that problem?

In WorkspaceInitialPage, we check to see if the active route of the sub-page of the workspace settings page is accessible.

App/src/pages/workspace/WorkspaceInitialPage.tsx

Lines 360 to 376 in 3baf965

	// We are checking if the user can access the route.
	// If user can't access the route, we are dismissing any modals that are open when the NotFound view is shown
	const canAccessRoute = activeRoute && menuItems.some((item) => item.routeName === activeRoute);
	useEffect(() => {
	if (!shouldShowNotFoundPage && canAccessRoute) {
	return;
	}
	if (wasRendered.current) {
	return;
	}
	wasRendered.current = true;
	// We are dismissing any modals that are open when the NotFound view is shown
	Navigation.isNavigationReady().then(() => {
	Navigation.closeRHPFlow();
	});
	}, [canAccessRoute, shouldShowNotFoundPage]);

If not, then we dismiss any RHP. For example, if the user opens a workspace as a member and tries to open the workspace categories setting, then the categories setting RHP will be dismissed and the not found page will show from the workspace categories list page.

In our case, we open the workspace's initial page. The active route becomes Workspace_Initial. However, the current canAccessRoute logic only checks for the sub-page route. So, when it compares the active route with itself, it fails because menuItems doesn't contain Workspace_Initial.

We actually have the logic to run it only once.

App/src/pages/workspace/WorkspaceInitialPage.tsx

Lines 368 to 371 in 3baf965

	if (wasRendered.current) {
	return;
	}
	wasRendered.current = true;

But when we open the search page, all routes are "hidden".

App/src/libs/Navigation/AppNavigator/createResponsiveStackNavigator/useStateWithSearch.ts

Lines 44 to 57 in 3baf965

	// On narrow layout, if we are on /search route we want to hide all central pane routes and show only the bottom tab navigator.
	if (lastSearchCentralPane) {
	const filteredRoute = filteredRoutes.at(0);
	if (filteredRoute) {
	return {
	stateToRender: {
	...state,
	index: 0,
	routes: [filteredRoute],
	},
	searchRoute: lastSearchCentralPane,
	};
	}
	}

So, the wasRendered logic in WorkspaceInitialPage won't work. And when we try to open the filter page, the previously "hidden" routes are added again to the stack and canAccessRoute becomes false which dismiss any RHP.

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

We can update canAccessRoute to cover the case of the workspace's initial page itself.

const canAccessRoute = activeRoute && (menuItems.some((item) => item.routeName === activeRoute) || activeRoute === SCREENS.WORKSPACE.INITIAL);

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

N/A

[ikevin127]

Proposal

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

Filter icon is not responsive when navigating to Search via WS chat in WS settings.

What is the root cause of that problem?

Note

This issue is only present on narrow layout devices (native / mWeb) where screens displayed in RHP act as a modal.

App/src/pages/workspace/WorkspaceInitialPage.tsx

Lines 360 to 376 in 3baf965

	// We are checking if the user can access the route.
	// If user can't access the route, we are dismissing any modals that are open when the NotFound view is shown
	const canAccessRoute = activeRoute && menuItems.some((item) => item.routeName === activeRoute);
	useEffect(() => {
	if (!shouldShowNotFoundPage && canAccessRoute) {
	return;
	}
	if (wasRendered.current) {
	return;
	}
	wasRendered.current = true;
	// We are dismissing any modals that are open when the NotFound view is shown
	Navigation.isNavigationReady().then(() => {
	Navigation.closeRHPFlow();
	});
	}, [canAccessRoute, shouldShowNotFoundPage]);

When we open the workspace's initial page, the active route becomes Workspace_Initial. However, the current canAccessRoute logic only checks for the sub-page route - therefore when it compares the active route with itself, it fails because menuItems doesn't contain Workspace_Initial.

We actually have the logic to only run it once here, but when we open the search page, all routes are "hidden" as explained here. Because of this, the wasRendered logic in WorkspaceInitialPage won't work as expected -> when we try to open the filter page, the previously "hidden" routes are added back to the stack and canAccessRoute becomes false which will dismiss any RHP that we try to open (Filters).

Credits to bernhardoj for the RCA.

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

We had a similar issue which I reviewed recently here where we navigated away from WorkspaceProfileSharePage to a report without dismissing the currently opened modal which caused a weird UI bug in the QR Code because the same modal would be opened twice.

A practical solution for this kind of issue which wouldn't break any other functionality is to simply replace the way we navigate away from WS to the report here:

App/src/pages/workspace/WorkspaceInitialPage.tsx

Line 457 in b595f5d

onPress={() => Navigation.navigate(ROUTES.REPORT_WITH_ID.getRoute(currentUserPolicyExpenseChat?.reportID ?? '-1'))}

to use Navigation.dismissModal instead:

onPress={() => Navigation.dismissModal(currentUserPolicyExpenseChat?.reportID ?? '-1')}

Why dismissing the modal first fixes our issue ?
Because as explained in RCA, on narrow layout devices (native / mWeb) screens displayed in RHP act as a modal and by dismissing it when navigating to the report, all the conditions which lead to the Filters RHP to being able to open when clicked on in our case, will now work as expected.

Result video (before / after)

iOS: Native

Before	After
before.mov	after.mov