[Due for payment 2026-01-23] [$250] Workspace setting-Taxes page still shown when disable the taxes from other browser

[mitarachim]

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.2.62-2
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: Edge Case retest A-50465 https://github.com/Expensify/Expensify/issues/441368
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Device used: Win 11/Chrome
App Component: Workspace Settings

Action Performed:

1. Open https://staging.new.expensify.com
2. Open any workspace > More features > Enable taxes.
3. Click on Taxes
4. Click on a tax rate
5. From the other browser, disable the taxes from the More features page.
6. Back to the first browser observe workspace setting page

Expected Result:

Taxes page should disappeared completely when disable the taxes from other browser

Actual Result:

RHP of tax rate page is closed but Taxes page still shown when disable the taxes from other browser.

(If didn't click on a any tax rate (RHP of tax rate page opened) at step 4 as following step of Edge Case retest https://github.com/Expensify/Expensify/issues/441368, Taxes page is disappeared)

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7010890_1763819136636.Recording__1524.mp4

Bug7010890_1763819136617.Taxes_disappeared_if_following_step_of_Edge_case_retest.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021994105962250703272
• Upwork Job ID: 1994105962250703272
• Last Price Increase: 2025-11-27

Issue Owner

Current Issue Owner: @trjExpensify

[melvin-bot]

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

[ryntgh]

Proposal

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

Workspace setting-Taxes page still shown when disable the taxes from other browser

What is the root cause of that problem?

When taxes are disabled from another browser while the Taxes Settings page has an RHP (Right Hand Panel) open, the navigation effect in AccessOrNotFoundWrapper doesn't run because the page is not focused (the RHP is focused instead)

The useEffect that navigates away when a feature is disabled checks isFocused at the beginning and returns early if the page is not focused

App/src/pages/workspace/AccessOrNotFoundWrapper.tsx

Lines 195 to 205 in 5375071

	useEffect(() => {
	if (!isFocused || isFeatureEnabled || (pendingField && !isOffline && !isFeatureEnabled)) {
	return;
	}
	// When a workspace feature linked to the current page is disabled we will navigate to the More Features page.
	Navigation.isNavigationReady().then(() => Navigation.goBack(ROUTES.WORKSPACE_MORE_FEATURES.getRoute(policyID)));
	// We don't need to run the effect on policyID change as we only use it to get the route to navigate to.
	// eslint-disable-next-line react-compiler/react-compiler
	// eslint-disable-next-line react-hooks/exhaustive-deps
	}, [pendingField, isOffline, isFeatureEnabled]);

However, isFocused is not included in the dependency array, so when the RHP closes and the page becomes focused again, the effect doesn't re-run to check if the feature is still disabled and navigate away

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

We should add isFocused to the dependency array of the useEffect that handles navigation when a feature is disabled

App/src/pages/workspace/AccessOrNotFoundWrapper.tsx

Lines 195 to 205 in 5375071

	useEffect(() => {
	if (!isFocused || isFeatureEnabled || (pendingField && !isOffline && !isFeatureEnabled)) {
	return;
	}
	// When a workspace feature linked to the current page is disabled we will navigate to the More Features page.
	Navigation.isNavigationReady().then(() => Navigation.goBack(ROUTES.WORKSPACE_MORE_FEATURES.getRoute(policyID)));
	// We don't need to run the effect on policyID change as we only use it to get the route to navigate to.
	// eslint-disable-next-line react-compiler/react-compiler
	// eslint-disable-next-line react-hooks/exhaustive-deps
	}, [pendingField, isOffline, isFeatureEnabled]);

What alternative solutions did you explore? (Optional)

NA

[etCoderDysto]

Proposal

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

Workspace setting-Taxes page still shown when disable the taxes from other browser

What is the root cause of that problem?

When isFocused is false, and when the feature is disabled, we return early and we avoid navigating back to features page

App/src/pages/workspace/AccessOrNotFoundWrapper.tsx

Lines 195 to 198 in 9b152f0

	useEffect(() => {
	if (!isFocused || isFeatureEnabled || (pendingField && !isOffline && !isFeatureEnabled)) {
	return;
	}

isFocused becomes false when the event isFocused event listener is subscribed from AccessNotFoundWrapper since AccessNotFoundWrapper is not a screen component the react navigation.

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

We should remove the !focused check

What alternative solutions did you explore? (Optional)

We can call useFocused from screens that render AccessNotFoundWrapper and pass it as prop to AccessNotFoundWrapper if the isFocused check is necessary. And we should add it as dependency to the useEffect.

[paulnjs]

Proposal

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

Workspace setting-Taxes page still shown when disable the taxes from other browser

What is the root cause of that problem?

When the Tax Rate RHP is opened, it is wrapped with the AccessOrNotFoundWrapper component. This wrapper contains logic to navigate to the "More Features" screen if the associated feature (in this case, Taxes) becomes disabled:

App/src/pages/workspace/AccessOrNotFoundWrapper.tsx

Lines 195 to 205 in 75971bc

	useEffect(() => {
	if (!isFocused || isFeatureEnabled || (pendingField && !isOffline && !isFeatureEnabled)) {
	return;
	}
	// When a workspace feature linked to the current page is disabled we will navigate to the More Features page.
	Navigation.isNavigationReady().then(() => Navigation.goBack(ROUTES.WORKSPACE_MORE_FEATURES.getRoute(policyID)));
	// We don't need to run the effect on policyID change as we only use it to get the route to navigate to.
	// eslint-disable-next-line react-compiler/react-compiler
	// eslint-disable-next-line react-hooks/exhaustive-deps
	}, [pendingField, isOffline, isFeatureEnabled]);

However, when the Taxes feature is disabled while the RHP is already open, the logic at:

App/src/pages/workspace/AccessOrNotFoundWrapper.tsx

Line 201 in 75971bc

Navigation.isNavigationReady().then(() => Navigation.goBack(ROUTES.WORKSPACE_MORE_FEATURES.getRoute(policyID)));

only dismisses the RHP, rather than navigating away from the page. As a result, the Taxes page content remains rendered.

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

We should explicitly dismiss the modal using Navigation.dismissModal() before calling the navigation logic

App/src/pages/workspace/AccessOrNotFoundWrapper.tsx

Line 201 in 75971bc

Navigation.isNavigationReady().then(() => Navigation.goBack(ROUTES.WORKSPACE_MORE_FEATURES.getRoute(policyID)));

To avoid unintended dismissals, we can first check if the RHP (modal) is currently open. If it is, we call Navigation.dismissModal(); afterward, we proceed with the existing navigation logic that redirects to the "More Features" screen.

What alternative solutions did you explore? (Optional)

N/A

[trjExpensify]

Could you say this bug is present for pretty much all of the features enabled in "More features" if you have the RHP open at the time of disabling the feature in another browser?

[paulnjs]

Could you say this bug is present for pretty much all of the features enabled in "More features" if you have the RHP open at the time of disabling the feature in another browser?

@trjExpensify Yes, the bug appears in other features as well

[trjExpensify]

Cool, let's fix it holistically. 👍