[HOLD for payment 2024-12-19] [$250] mWeb - Selector - User lands on the same WS when double tapping on different one on selector

[IuliiaHerets]

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.0.53-0
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail: https://expensify.testrail.io/index.php?/tests/view/5122323&group_by=cases:section_id&group_order=asc&group_id=296775
Issue reported by: Applause Internal Team

Action Performed:

1. Open the staging.new.expensify.com website.
2. Tap on Workspace selector on the top left corner.
3. Change to any workspace on the list.
4. Double tap on Expensify option.
5. Verify that all the chats are displayed in LHN.
6. Open Workspace selector again.
7. Double tap on the next workspace to the one selected.
8. Verify that the chats of the selected workspace are displayed.

Expected Result:

LHN should display the selected workspace chats when the user double taps over it in selector.

Actual Result:

User remains on the same workspace when trying to select "Expensify" option or next workspace on the selector list with double tapping.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug6643981_1729740526844.Selector_WS.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021849976484014852041
• Upwork Job ID: 1849976484014852041
• Last Price Increase: 2024-11-09
• Automatic offers:
• Krishna2323 | Contributor | 104866093

Issue Owner

Current Issue Owner: @stephanieelliott

[melvin-bot]

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

[IuliiaHerets]

We think that this bug might be related to #wave-collect - Release 1

[IuliiaHerets]

@stephanieelliott FYI I haven't added the External label as I wasn't 100% sure about this issue. Please take a look and add the label if you agree it's a bug and can be handled by external contributors

[nyomanjyotisa]

Proposal

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

Selector - User lands on the same WS when double tapping on different one on selector

What is the root cause of that problem?

On double click, only Navigation.goBack() executed on the second click, and the Navigation.navigateWithSwitchPolicyID({policyID}) not executed since policyID !== activeWorkspaceID is true on second click

App/src/pages/WorkspaceSwitcherPage/index.tsx

Lines 85 to 100 in 09f19c3

	const selectPolicy = useCallback(
	(option?: WorkspaceListItem) => {
	if (!option) {
	return;
	}
	const {policyID} = option;
	setActiveWorkspaceID(policyID);
	Navigation.goBack();
	if (policyID !== activeWorkspaceID) {
	Navigation.navigateWithSwitchPolicyID({policyID});
	}
	},
	[activeWorkspaceID, setActiveWorkspaceID],
	);

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

Implement debouncing to prevent double click

    const selectPolicy = useCallback(
        debounce((option?: WorkspaceListItem) => {
            console.log("set policy")

            if (!option) {
                return;
            }

            const {policyID} = option;

            setActiveWorkspaceID(policyID);
            Navigation.goBack();
            if (policyID !== activeWorkspaceID) {
                Navigation.navigateWithSwitchPolicyID({policyID});
            }
        }, 300),
        [activeWorkspaceID, setActiveWorkspaceID],
    );

What alternative solutions did you explore? (Optional)

[Krishna2323]

Edited by proposal-police: This proposal was edited at 2024-10-27 22:00:21 UTC.

Proposal


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

mWeb - Selector - User lands on the same WS when double tapping on different one on selector

What is the root cause of that problem?

• Double navigation is happening because the Navigation.goBack(); & Navigation.navigateWithSwitchPolicyID({policyID}); is called twice when double clicking.
  

  App/src/pages/WorkspaceSwitcherPage/index.tsx

  Lines 85 to 100 in 81e877a

  	const selectPolicy = useCallback(
  	(option?: WorkspaceListItem) => {
  	if (!option) {
  	return;
  	}
  	const {policyID} = option;
  	setActiveWorkspaceID(policyID);
  	Navigation.goBack();
  	if (policyID !== activeWorkspaceID) {
  	Navigation.navigateWithSwitchPolicyID({policyID});
  	}
  	},
  	[activeWorkspaceID, setActiveWorkspaceID],
  	);

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


• We can use useIsFocused hook to check if the screen is focused or not and if the screen is not focused we will return early from selectPolicy .

    const isFocused = useIsFocused();

    const selectPolicy = useCallback(
        (option?: WorkspaceListItem) => {
            if (!option || !isFocused) {
                return;
            }

            const {policyID} = option;

            setActiveWorkspaceID(policyID);
            Navigation.goBack();
            if (policyID !== activeWorkspaceID) {
                Navigation.navigateWithSwitchPolicyID({policyID});
            }
        },
        [activeWorkspaceID, setActiveWorkspaceID, isFocused],

What alternative solutions did you explore? (Optional)

• Instead of using Navigation.goBack();, we can use Navigation.dismissModal();.
  

  App/src/pages/WorkspaceSwitcherPage/index.tsx

  Line 94 in 81e877a

  Navigation.goBack();

Result

[melvin-bot]

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

[melvin-bot]

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

[s77rt]

@nyomanjyotisa Thanks for the proposal. Do you know why this happens on mWeb Chrome only?

[s77rt]

@Krishna2323 Thanks for the proposal. Same question ^ any idea why this does not happen on other platforms?

[Krishna2323]

@s77rt, It also happens on mWeb Safari, though I don’t have a clear understanding of why it behaves differently. I think this is the default behavior of mobile web, and it totally depends on how quickly the pressables are removed from the screen after selecting an option. I have also added an alternative solution in my proposal, please let me know your thoughts on that.

bug_ios_safari_double_tap.mp4

[s77rt]

@Krishna2323 Thanks for the update. I think using dismissModal makes more sense. Can you please check if this works as expected when using the browser's back button? Also what will happen on the second execution of that function? (Let's double check this does not cause unwanted side effects)

[s77rt]

@Krishna2323 Did dimissModal work for you? From my testing I'm still getting the same bug

[Krishna2323]

@s77rt, works perfectly on my machine.

double_navigation_workspace_switcher.mp4

[Krishna2323]

Also what will happen on the second execution of that function? (Let's double check this does not cause unwanted side effects)

• I think a more better way is to just call Navigation.dismissModal(); and return if policyID === activeWorkspaceID. What do you think. Updating Navigation.goBack(); to Navigation.dismissModal(); is also safe as per my testing.
• We can also remove Navigation.goBack(); because the navigation will be handled by Navigation.navigateWithSwitchPolicyID({policyID}); in case policyID !== activeWorkspaceID is true.

    const selectPolicy = useCallback(
        (option?: WorkspaceListItem) => {
            if (!option) {
                return;
            }

            const {policyID} = option;
            if (policyID === activeWorkspaceID) {
                Navigation.dismissModal();
                return;
            }

            setActiveWorkspaceID(policyID);
            Navigation.goBack();
            if (policyID !== activeWorkspaceID) {
                Navigation.navigateWithSwitchPolicyID({policyID});
            }
        },
        [activeWorkspaceID, setActiveWorkspaceID],
    );

[s77rt]

@Krishna2323 I think we still have another problem. After the first click the activeWorkspaceID is changed and so the position of the selected workspace. Now the second click is made on the previous workspace and causes same bug.

Screen.Recording.2024-10-29.at.9.04.05.AM.mov

First click:

Second click:

[s77rt]

Screen.Recording.2024-10-29.at.9.16.15.AM.mov

[Krishna2323]

@s77rt, what do you think about using isFocused state? isFocused is used in multiple places to fix similar bugs.

App/src/pages/home/report/ReportActionCompose/AttachmentPickerWithMenuItems.tsx

Lines 296 to 301 in d78be88

	onPress={(e) => {
	e?.preventDefault();
	if (!isFocused) {
	return;
	}
	onAddActionPressed();

App/src/pages/workspace/WorkspaceMembersPage.tsx

Lines 151 to 159 in d78be88

	// useFocus would make getWorkspaceMembers get called twice on fresh login because policyEmployee is a dependency of getWorkspaceMembers.
	useEffect(() => {
	if (!isFocused) {
	setSelectedEmployees([]);
	return;
	}
	getWorkspaceMembers();
	// eslint-disable-next-line react-compiler/react-compiler, react-hooks/exhaustive-deps
	}, [isFocused]);

[s77rt]

@Krishna2323 I think that would be a workaround because the selectPolicy callback is not really expected to be called if the screen is not focused. I'm not sure how such case can be handled but let's try explore more options for now. Do you know if this is a new bug? or if we the bug exist on other places?

[melvin-bot]

@s77rt, @stephanieelliott Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[s77rt]

Still looking for proposals

[Krishna2323]

@s77rt, I found this bug which is very similar to ours and was solved using isFocused state.

[stephanieelliott]

PR is in review

[stephanieelliott]

PR is moving along, @Krishna2323 is working on some tests

[stephanieelliott]

PR is still under review, seems like we were stuck on some testing but @s77rt shared a helpful example to work off of

[melvin-bot]

This issue has not been updated in over 15 days. @s77rt, @blimpich, @stephanieelliott, @Krishna2323 eroding to Monthly issue.

P.S. Is everyone reading this sure this is really a near-term priority? Be brave: if you disagree, go ahead and close it out. If someone disagrees, they'll reopen it, and if they don't: one less thing to do!

[s77rt]

Still working on UI test

[melvin-bot]

Reviewing label has been removed, please complete the "BugZero Checklist".

[melvin-bot]

The solution for this issue has been 🚀 deployed to production 🚀 in version 9.0.74-8 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• fix: mWeb - Selector - User lands on the same WS when double tapping on different one on selector. #52438

If no regressions arise, payment will be issued on 2024-12-19. 🎊

For reference, here are some details about the assignees on this issue:

• @s77rt requires payment through NewDot Manual Requests
• @Krishna2323 requires payment automatic offer (Contributor)

[melvin-bot]

@s77rt @stephanieelliott @s77rt The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the BugZero Checklist from here into a new comment on this GH and complete it. If you have the K2 extension, you can simply click: [this button]

[s77rt]

BugZero Checklist:

• [Contributor] Classify the bug:

Bug classification

Source of bug:

• 1a. Result of the original design (eg. a case wasn't considered)
• 1b. Mistake during implementation
• 1c. Backend bug
• 1z. Other:

Where bug was reported:

• 2a. Reported on production (eg. bug slipped through the normal regression and PR testing process on staging)
• 2b. Reported on staging (eg. found during regression or PR testing)
• 2d. Reported on a PR
• 2z. Other:

Who reported the bug:

• 3a. Expensify user
• 3b. Expensify employee
• 3c. Contributor
• 3d. QA
• 3z. Other:

• [Contributor] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake.

  Link to comment: [Wave 8] Ideal nav  #33280 (comment)

• [Contributor] If the regression was CRITICAL (e.g. interrupts a core flow) A discussion in #expensify-open-source has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner.

  Link to discussion: n/a

• [Contributor] If it was decided to create a regression test for the bug, please propose the regression test steps using the template below to ensure the same bug will not reach production again.

  Bug requires regression test: No. We have already added a UI test that covers this

Regression Test Proposal Template

• [BugZero Assignee] Create a GH issue for creating/updating the regression test once above steps have been agreed upon.

  Link to issue:

Regression Test Proposal

Precondition:

Test:

Do we agree 👍 or 👎

[melvin-bot]

@s77rt, @blimpich, @stephanieelliott, @Krishna2323 Eep! 4 days overdue now. Issues have feelings too...

[melvin-bot]

@s77rt, @blimpich, @stephanieelliott, @Krishna2323 Still overdue 6 days?! Let's take care of this!

[s77rt]

This is only awaiting payment. I have requested in ND. @stephanieelliott Please handle the payment for @Krishna2323 then we can close.

[melvin-bot]

@s77rt, @blimpich, @stephanieelliott, @Krishna2323 8 days overdue is a lot. Should this be a Weekly issue? If so, feel free to change it!