[HOLD for payment 2024-04-15] [$1000] Infinite loading on Invite members page after refresh

[kavimuru]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Action Performed:

1. Go to Settings > Workspaces
2. Select any workspace
3. Go to Members > Invite
4. Refresh website

Expected Result:

Show contacts list to invite

Actual Result:

Show skeleton forever

Workaround:

Can the user still use Expensify without this being fixed? Have you informed them of the workaround?

Platforms:

Which of our officially supported platforms is this issue occurring on?

• Android / native
• Android / Chrome
• iOS / native
• iOS / Safari
• MacOS / Chrome / Safari
• MacOS / Desktop

Version Number: 1.3.38-2
Reproducible in staging?: y
Reproducible in production?: y
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation

bug.3.mov

Expensify/Expensify Issue URL:
Issue reported by: @situchan
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1688833373673129

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~0160eb205488d8fcdd
• Upwork Job ID: 1691081434892730368
• Last Price Increase: 2023-12-26
• Automatic offers:
• situchan | Contributor | 0
• bernhardoj | Contributor | 0

[melvin-bot]

Triggered auto assignment to @muttmuure (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

[melvin-bot]

Bug0 Triage Checklist (Main S/O)

• This "bug" occurs on a supported platform (ensure Platforms in OP are ✅)
• This bug is not a duplicate report (check E/App issues and #expensify-bugs)
  • If it is, comment with a link to the original report, close the issue and add any novel details to the original issue instead
• This bug is reproducible using the reproduction steps in the OP. S/O
  • If the reproduction steps are clear and you're unable to reproduce the bug, check with the reporter and QA first, then close the issue.
  • If the reproduction steps aren't clear and you determine the correct steps, please update the OP.
• This issue is filled out as thoroughly and clearly as possible
  • Pay special attention to the title, results, platforms where the bug occurs, and if the bug happens on staging/production.
• I have reviewed and subscribed to the linked Slack conversation to ensure Slack/Github stay in sync

[samh-nl]

Proposal

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

Refreshing when viewing the invite members page in a workspace shows it's loading permanently.

What is the root cause of that problem?

The OptionsSelector component is only allowed to show its options after a transitionEnd event has fired.

App/src/pages/workspace/WorkspaceInvitePage.js

Lines 270 to 272 in 395f4a7

	<ScreenWrapper shouldEnableMaxHeight>
	{({didScreenTransitionEnd}) => {
	const sections = didScreenTransitionEnd ? this.getSections() : [];

App/src/pages/workspace/WorkspaceInvitePage.js

Line 296 in 395f4a7

shouldShowOptions={didScreenTransitionEnd && OptionsListUtils.isPersonalDetailsReady(this.props.personalDetails)}

This event is normally fired when moving between screens, i.e. when navigating to the 'invite members page' indirectly (by clicking Workspace > Members > Invite).

However, when directly browsing to it, there is no transition happening and didScreenTransitionEnd therefore remains false. This causes the loader to remain permanently.

This issue also exists in other components where loading is blocked until didScreenTransitionEnd is set to true, including TaskAssigneeSelectorModal and TaskShareDestinationSelectorModal. In two other situations, NewChatPage and SearchPage, this also applies however the problem is masked due to a navigation to a report occurring upon load, which triggers the transitionEnd event and therefore the problem does not become visible here.

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

Option 1: Instead of setting didScreenTransitionEnd to true upon the firing of transitionEnd, we can use InteractionManager.runAfterInteractions.

Option 2: We can use InteractionManager.runAfterInteractions as a fallback mechanism, i.e. use both.

What alternative solutions did you explore? (Optional)

N/A

[tienifr]

Proposal

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

Infinite loading on Invite members page after refresh

What is the root cause of that problem?

In

App/src/pages/workspace/WorkspaceInvitePage.js

Line 296 in 395f4a7

shouldShowOptions={didScreenTransitionEnd && OptionsListUtils.isPersonalDetailsReady(this.props.personalDetails)}

We just show the option if didScreenTransitionEnd is true, and didScreenTransitionEnd is updated to true when transitionEnd event is triggered.

App/src/components/ScreenWrapper/index.js

Lines 37 to 45 in 395f4a7

	componentDidMount() {
	this.unsubscribeTransitionEnd = this.props.navigation.addListener('transitionEnd', (event) => {
	// Prevent firing the prop callback when user is exiting the page.
	if (lodashGet(event, 'data.closing')) {
	return;
	}
	this.setState({didScreenTransitionEnd: true});
	this.props.onEntryTransitionEnd();
	});

But if we visit the page directly, the transitionEnd event is not triggered because there's no transition happens. transitionEnd event is triggered when we execute Navigation.navigate

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

transitionEnd event is triggered when we execute Navigation.navigate so I suggest creating the new variable didNavigate in Navigation.js. We will init didNavigate=false and update it to true when we execute navigate function.

let didNavigate = false;
...
function navigate(route = ROUTES.HOME, type) {
    if(!didNavigate){
        didNavigate=true;
    }
...

function shouldDisableTransitionEnd(){
    return !didNavigate
}

And in ScreenWrapper, we can early set didScreenTransitionEnd to true if didNavigate is false

    componentDidMount() {
        if(Navigation.shouldDisableTransitionEnd()){
            this.setState({didScreenTransitionEnd: true});
            this.props.onEntryTransitionEnd();
            return; 
        }

What alternative solutions did you explore? (Optional)

Another approach to fix this is part B in this solution (it's a related issue).

Result

Screen.Recording.2023-07-10.at.18.24.10.mov

[muttmuure]

I'm not able to reproduce this one.

[situchan]

This is still reproducible to everyone.
@muttmuure if you're not able to reproduce, can you please ask another BZ member internally?

[melvin-bot]

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.