Closed kbecciv closed 6 months ago
Job added to Upwork: https://www.upwork.com/jobs/~0124a682d645bc91de
Triggered auto assignment to Contributor-plus team member for initial proposal review - @rushatgabhane (External
)
Triggered auto assignment to @adelekennedy (Bug
), see https://stackoverflow.com/c/expensify/questions/14418 for more details.
We think that this bug might be related #wave8-collect-admins CC @zanyrenney
This seems to be a regression caused by https://github.com/expensify/App/commit/404b0b65ec58bbe3b072d366d78f266f8de832bd which is part of a large PR. Reverting this commit solves the problem but I'm sure it will break whatever that commit fixed (I could not find any references to it), so I'm not gonna make a formal proposal yet.
Let's fix the issue then instead of reverting
@rushatgabhane, @adelekennedy Whoops! This issue is 2 days overdue. Let's get this updated quick!
looking for proposals
@kosmydel would you be able to provide more insights on this commit: https://github.com/Expensify/App/commit/404b0b65ec58bbe3b072d366d78f266f8de832bd
My understanding is that StackActions.popToTop
goes back to the first screen in the stack, while StackActions.pop
goes back to the previous one, which is what we want here.
π£ It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? πΈ
The current issue pertains to the functionality of the back button in profile settings, which erroneously navigates to the conversation before workspace switching.
When the user selects a workspace from the workspace switcher, The code first executes Navigation.goBack(), navigating to the previous screen in the stack. And only after that it checks if it has to switch to new screen.
Navigation.goBack();
if (policyID !== activeWorkspaceID) {
Navigation.navigateWithSwitchPolicyID({policyID, isPolicyAdmin});
}
Instead of unconditionally navigating back to the previous screen, We only navigate to the previous screen if and only if the user selects the same or active workspace. Otherwise, it directly navigates to the new workspace.
if (policyID !== activeWorkspaceID) {
Navigation.navigateWithSwitchPolicyID({policyID, isPolicyAdmin});
} else {
Navigation.goBack();
}
Here If a new workspace was selected, the first screen of that new workspace will be the "top" of the stack, since we're not navigating back before switching workspace.
Updated Result:
https://github.com/Expensify/App/assets/32809050/2780ecfe-b3d9-4035-a479-8ccc9ee34754
We can simply use .pop() instead of .popToTop(). However, it is too slow. So above solution is fast and robust and solves the problem from the root.
@rushatgabhane, @adelekennedy Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!
waiting for additional proposals
[deleted]
Clicking the back button in profile settings will not take you back to the same conversation.
The root cause of this problem is this commit: https://github.com/Expensify/App/commit/404b0b65ec58bbe3b072d366d78f266f8de832bd
It replaced pop
with popToTop
which makes the navigator navigate back to the first screen and not the previous one.
Reverting https://github.com/Expensify/App/commit/404b0b65ec58bbe3b072d366d78f266f8de832bd is not really an option here because the change was made to solve another problem. We can also see by this comment that pop
is the right method to call here but it does cause delays, which we also don't want.
I also found some interesting things when using pop
(this only applies to Web). For example, when we use pop
, we the browser's forward navigation will activate, which means the pop behaves similarly to the browser's back button. If you go to settings, then navigate to Wallet, then Preferences, then Security and then click the back button, you'd be able to hit forward and backtrack these steps (although it doesn't appear to always be that way).
With popToTop
, nont of this happens. It behaves as we would expect, it pushes a new url to the history and you can hit back on the browser's button to go back to the settings back, etc.. Except that it does not work :)
Going back to the OG problem, where pop
adds a delay, I found this commit that's interesting:
https://github.com/react-navigation/react-navigation/commit/b1f13774295465942aafa1b0ff611b9eebccbd77
Looks like react-navigation
adds some artificial delay when navigating under certain codnitions. I didn't dig too deep but this could be the reason why we see a slight delay when using pop
.
So, popToTop
is not the correct method, it doesn't do what we need, and while pop
does, it has a delay and on web it acts as clicking the browser's back button which IMO is wrong. Clicking the < button on the app shouldn't bring us "back", we're moving "forward" to the previous url, if that makes sense.
My proposed solution for this problem is to rewrite closeFullScreen
to be like this:
function closeFullScreen() {
const rootState = navigationRef.getRootState();
if(rootState.routes.length < 2) {
navigationRef.dispatch({...StackActions.popToTop(), target: rootState.key});
}
const parentRoute = rootState.routes[rootState.routes.length - 2];
navigationRef.dispatch({...StackActions.push(parentRoute.name, parentRoute.params), target: rootState.key});
}
This will use the push
method to navigate us forward
to the previous screen, but grabbing the previous screen in the stack and navigating to it. This will make the app navigate to the correct page, without the delay and as a bonus will not break the browser's back/forward navigation.
The check for length < 2
was added as a failsafe but I believe that scenario won't happen, especially because closeFullScreen
is only used in one place throughout the entire codebase.
EDIT: This doesn't really work well on mobile because hitting back is "navigating forward" and the navigation animation is not correct. Also, I believe using push
adds another stack on top and I don't think this is a good thing as we want to remove the top screen out of the stack instead of adding another screen on top of it. I'll leave this proposal up as there might still be some good info in here.
Proceed with reverting https://github.com/Expensify/App/commit/404b0b65ec58bbe3b072d366d78f266f8de832bd and dealing with the delay issue separately. The original fix for the delay issue was wrong and should be reverted and a new fix for the delay should be created.
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.
Clicking the back button in profile settings navigates to the first conversation instead of the previous conversation.
The root cause of this problem is the use of the popToTop
method here in closeFullScreen
, which navigates back to the first screen in the stack, instead of navigating to the previous screen.
To solve this problem, we should replace the use of popToTop
with the navigate
action. The navigate
action allows us to navigate to a specific route, and if that route already exists in the stack, it will go back to that screen and remove any screens after that. This behavior aligns with our desired outcome of navigating back to the previous conversation and keeps the visuals on mobile in order as well as the stack order.
function closeFullScreen() {
const rootState = navigationRef.getRootState();
if (rootState.routes.length < 2) {
navigationRef.dispatch({...StackActions.popToTop(), target: rootState.key});
} else {
const previousRoute = rootState.routes[rootState.routes.length - 2];
navigationRef.dispatch({...StackActions.push(previousRoute.name, previousRoute.params), target: rootState.key});
}
}
In this implementation, we first check if there are at least two routes in the stack. If there are fewer than two routes, we use popToTop
to navigate to the first screen. Otherwise, we use the navigate
action to go back to the previous route.
closeFullScreen
function and just use the goBack
method from this same file. After navigation around various chats and workspaces and then the user brings up the Profile page, when user click the Left Chevron at the top left it does not go back to the last chat page viewed. The user expectation is it should go back to the chat page immediately before opening the Profile page.
The root cause of the problem is the wrong action is called when the Left Chevron is clicked. StackActions.popToTop()
is the wrong action introduced in 404b0b6
We should revert 404b0b6 to restore correct functionality of the Left Chevron.
404b0b6 was supposed to fix "Clicking back from the Account Settings back in top left corner takes noticeably longer to open the chats then other back buttons" but I have not been able to reproduce this slower performance on Web. We should fix this issue (#36509) now because it's broken functionality which is more important than performance. Separately, another issue should be opened to properly investigate and address the slower performance. It's possible this performance issue no longer exists.
@kosmydel would you be able to provide more insights on this commit: 404b0b6
My understanding is that
StackActions.popToTop
goes back to the first screen in the stack, whileStackActions.pop
goes back to the previous one, which is what we want here.
The StackActions.pop
function goes back to the previous screen. The problem with it is, that it is noticeably slow. Switching to popToTop
helped, but apparently, it introduced this bug.
We can consider switching back to the .pop
function, however, this will result in a slower performance (and that is probably not what we want). On the other hand, pressing the browser back button is also slow (the performance is similar to what we have with the .pop
function).
So the aim is, to find a solution, which will be both performant and not use the popToTop
function.
Proposals to review above - we're just coming back from the weekend
@rushatgabhane @adelekennedy this issue was created 2 weeks ago. Are we close to approving a proposal? If not, what's blocking us from getting this issue assigned? Don't hesitate to create a thread in #expensify-open-source to align faster in real time. Thanks!
on my plate
π£ It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? πΈ
~I like @bi-kash's proposal https://github.com/Expensify/App/issues/36509#issuecomment-1959508184~
~π π π~
Triggered auto assignment to @tgolen, see https://stackoverflow.com/c/expensify/questions/7972 for more details.
@tgolen the root cause is using StackActions.popToTop
because it takes you to first screen in stack. https://github.com/Expensify/App/issues/36509#issuecomment-1964380991
I need your feedback on next steps.
I think the solution should be to
StackActions.pop
A stack pop
action should be O(1)
, we should investigate if it's an issue in react navigation
What do you think?
@barros001 the commit you're referring to in react navigation is 4 years old. I can't find it in main
branch. Maybe they removed the delay?
OK, I read through most of this issue and I hope I caught everything. I understand the focus on pop
and popToTop
but I am concerned that it could have far-reaching effects across the app. Are we sure we want to affect the entire app?
If so, then I think this problem is not really related to the workspace selector only, and that's just one way the problem is manifesting. I agree with Rushat's plan to fix that.
If we don't want to affect the entire app, then @bi-kash's proposal is the correct one I think.
@barros001 the commit you're referring to in react navigation is 4 years old. I can't find it in
main
branch. Maybe they removed the delay?
Very possible. My bad though, I should've looked deeper before mentioning a 4 year old commit.
No worries, it's all good :)
@tgolen, @rushatgabhane, @adelekennedy Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!
@rushatgabhane How do you want to move forward on this one? Is the root problem happening elsewhere in the app and this should be a holistic solution for the entire app? OR does this problem only affect this single flow and a more simple fix is in order?
Issue not reproducible during KI retests. (First week)
Yeah sure! Let me deep dive what to do here
@tgolen @rushatgabhane @adelekennedy this issue is now 3 weeks old. There is one more week left before this issue breaks WAQ and will need to go internal. What needs to happen to get a PR in review this week? Please create a thread in #expensify-open-source to discuss. Thanks!
@tgolen I think we should measure the delay of StackActions.pop
vs StackActions. popToTop
.
If the delay is measureable and user can feel the lag, then we could go with @bi-kash's proposal because I can't find this issue happening anywhere else in the app.
If there are no posts, I'll find a way to measure the delay over the weekend.
Besides the delay issue there is also this issue https://github.com/Expensify/App/issues/36900
@tgolen, @rushatgabhane, @adelekennedy Whoops! This issue is 2 days overdue. Let's get this updated quick!
clearing the overdue here - @rushatgabhane were you able to measure the delay over the weekend?
I've added this to wave collect as I think it belongs there and under the Release 1 status
@tgolen @rushatgabhane @adelekennedy this issue is now 4 weeks old and preventing us from maintaining WAQ, can you:
Thanks!
Current assignee @rushatgabhane is eligible for the Internal assigner, not assigning anyone new.
Hey, now that we've removed back button from the full screen modal, do we really need to fix this bug?
It can't be reproduced after click browser back. The function closeFullScreen
where the root cause is isn't being used.
That's a good point. It's a shame that closeFullScreen
has been abandoned. It should be cleaned up now. I'm going to reduce the bounty of this issue to $100 and change the scope to just be a simple cleanup.
Upwork job price has been updated to $100
@trjExpensify with the change above should this be under polish vs release 1?
Let's hire @barros001 because they were first to mention the root cause? https://github.com/Expensify/App/issues/36509#issuecomment-1961909146
@tgolen πππ
Current assignee @tgolen is eligible for the choreEngineerContributorManagement assigner, not assigning anyone new.
yep, polish makes sense.
The back button was removed from the modals and so now the
closeFullScreen()
method is no longer used in the code, but it was never removed. Let's remove it!Old Issue Description
If you havenβt already, check out our [contributing guidelines](https://github.com/Expensify/ReactNativeChat/blob/main/contributingGuides/CONTRIBUTING.md) for onboarding and email contributors@expensify.com to request to join our Slack channel! ___ **Version Number:** v1.4.41-3 **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 **Expensify/Expensify Issue URL:** **Issue reported by:** Applause - Internal **Slack conversation:** ## Action Performed: Precondition: - Workspace filter is set to "Expensify". 1. Go to staging.new.expensify.com 2. Go to any chat and send a message. 3. Open workspace switcher. 4. Select any workspace. 5. Click Profile settings. 6. Click back button on the top left. ## Expected Result: App closes profile settings and reopens the chat that shows up after switching workspace in Step 4. ## Actual Result: App reopens the chat that is opened in Step 2, which is before workspace filter is applied, while the workspace filter is still applied. ## Workaround: Unknown ## Platforms: Which of our officially supported platforms is this issue occurring on? - [ ] Android: Native - [ ] Android: mWeb Chrome - [ ] iOS: Native - [ ] iOS: mWeb Safari - [x] MacOS: Chrome / Safari - [x] MacOS: Desktop ## Screenshots/Videos Add any screenshot/video evidence https://github.com/Expensify/App/assets/93399543/32828cc3-8d1c-4347-a25d-f7b624a03cccView all open jobs on GitHub
Upwork Automation - Do Not Edit
Issue Owner
Current Issue Owner: @adelekennedy