Categories - Category list closes with delay after changing the default spend category

[mitarachim]

If you haven’t already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!

---

Version Number: 9.1.3-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught on HybridApp, is this reproducible on New Expensify Standalone?: N/A
If this was caught during regression testing, add the test name, ID and link from TestRail: Exp
Email or phone of affected tester (no customers): [email protected]
Issue reported by: Applause Internal Team
Device used: Mac 15.0 / Chrome
App Component: Workspace Settings

Action Performed:

1. Go to staging.new.expensify.com
2. Go to workspace settings > Categories.
3. Click Settings.
4. Open any spend.
5. Select a different category.
6. Repeat Step 4 and 5 a few times.

Expected Result:

Category list will close without delay after changing the default spend category.

Actual Result:

Category list closes with delay after changing the default spend category.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug6749813_1740124022131.20250221_154306.mp4

View all open jobs on GitHub

[melvin-bot]

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

[jjcoffee]

Seems like a regression from #56792.

[daledah]

Proposal

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

Category list closes with delay after changing the default spend category.

What is the root cause of that problem?

When selecting a new category, we use InteractionManager.runAfterInteractions to delay

App/src/pages/workspace/categories/WorkspaceCategoriesSettingsPage.tsx

Lines 88 to 90 in 9d8eef2

	InteractionManager.runAfterInteractions(() => {
	setIsSelectorModalVisible(false);
	});

This was added to fix this issue, but it causes more delays on web.

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

We should use Navigation.setNavigationActionToMicrotaskQueue instead of InteractionManager.runAfterInteractions, which has less delay on web while still fixes the bug in #55956 on android

Screen.Recording.2025-02-21.at.16.08.33.mov

Screen.Recording.2025-02-21.at.16.09.31.mov

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

None

What alternative solutions did you explore? (Optional)

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.

[allgandalf]

Yeah regression from

• [Due for payment 2025-02-25] [$250] Android - Categories - Previously selected category and keypad is shown briefly #55956.

c.c. @Ollyws @FitseTLT

[FitseTLT]

This is intentional we want to delay the navigation to avoid displaying the old data. I was intending initially to apply the delay for only mobile via canUseTouchScreen but @Ollyws comment here says the problem exists on web too. Isn't it correct @Ollyws ?