You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[HOLD for payment 2024-04-15] [$1000] Infinite loading on Invite members page after refresh #22508
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
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)
// 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
Activity
melvin-bot commentedon Jul 9, 2023
Triggered auto assignment to @muttmuure (
Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.melvin-bot commentedon Jul 9, 2023
Bug0 Triage Checklist (Main S/O)
Platformsin OP are ✅)samh-nl commentedon Jul 10, 2023
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
OptionsSelectorcomponent is only allowed to show its options after atransitionEndevent has fired.App/src/pages/workspace/WorkspaceInvitePage.js
Lines 270 to 272 in 395f4a7
App/src/pages/workspace/WorkspaceInvitePage.js
Line 296 in 395f4a7
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
didScreenTransitionEndtherefore remains false. This causes the loader to remain permanently.This issue also exists in other components where loading is blocked until
didScreenTransitionEndis set to true, includingTaskAssigneeSelectorModalandTaskShareDestinationSelectorModal. In two other situations,NewChatPageandSearchPage, this also applies however the problem is masked due to a navigation to a report occurring upon load, which triggers thetransitionEndevent 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
didScreenTransitionEndto true upon the firing oftransitionEnd, we can useInteractionManager.runAfterInteractions.Option 2: We can use
InteractionManager.runAfterInteractionsas a fallback mechanism, i.e. use both.What alternative solutions did you explore? (Optional)
N/A
tienifr commentedon Jul 10, 2023
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
We just show the option if didScreenTransitionEnd is true, and didScreenTransitionEnd is updated to true when
transitionEndevent is triggered.App/src/components/ScreenWrapper/index.js
Lines 37 to 45 in 395f4a7
But if we visit the page directly, the
transitionEndevent is not triggered because there's no transition happens.transitionEndevent is triggered when we execute Navigation.navigateWhat changes do you think we should make in order to solve the problem?
transitionEndevent 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.And in ScreenWrapper, we can early set didScreenTransitionEnd to true if didNavigate is false
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 commentedon Jul 12, 2023
I'm not able to reproduce this one.
situchan commentedon Jul 18, 2023
This is still reproducible to everyone.
@muttmuure if you're not able to reproduce, can you please ask another BZ member internally?
melvin-bot commentedon Jul 25, 2023
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.
huzaifa-99 commentedon Jul 25, 2023
@muttmuure This is still reproducible. @kavimuru can you please confirm?
136 remaining items
rlinoz commentedon Apr 29, 2024
@situchan is OOO https://expensify.slack.com/archives/C02NK2DQWUX/p1711774859535809
muttmuure commentedon Apr 30, 2024
Moving to Monthly while @situchan is out. Feel free to tag me when you're back and I'll process it
muttmuure commentedon May 8, 2024
Waiting for @situchan to accept the offer
situchan commentedon May 17, 2024
Sorry for late. Accepted
rlinoz commentedon Jun 17, 2024
@muttmuure moving back to daily since @situchan is back
muttmuure commentedon Jun 19, 2024
Paid up