[$250] Book travel - Book travel animation becomes blank while RHP is dismissed

[lanitochka17]

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

---

Version Number: 9.0.40-0
Reproducible in staging?: Y
Reproducible in production?: N
If this was caught during regression testing, add the test name, ID and link from TestRail: N/A
Email or phone of affected tester (no customers): applausetester+kh230901@applause.expensifail.com
Issue reported by: Applause - Internal Team

Action Performed:

1. Go to staging.new.expensify.com
2. Open FAB
3. Click Book travel
4. Dismiss the RHP

Expected Result:

Book travel animation will not become blank while RHP is dismissed

Actual Result:

Book travel animation becomes blank while RHP is dismissed

Workaround:

Unknown

Platforms:

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

• Android: Native
• Android: mWeb Chrome
• iOS: Native
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

Bug6615160_1727291080522.20240926_020845.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021840763606281462254
• Upwork Job ID: 1840763606281462254
• Last Price Increase: 2024-09-30

Issue Owner

Current Issue Owner: @

[melvin-bot]

Triggered auto assignment to @MonilBhavsar (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[rushatgabhane]

don't know what caused it, but def NOT A BLOCKER

[Nodebrute]

This happens with all the animations, like on the wallet, security, and troubleshoot pages.

[rushatgabhane]

let's close 😄

[MonilBhavsar]

Thanks for looking! Demoting from blocker, but let's try if we can fix it

[neonbhai]

Proposal

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

Default name in name field displays user/report ID instead of user/report name

What is the root cause of that problem?

This happens as we render an empty view here if the user has navigated away. The issue we set hasNavigatedAway quickly before the RHP animation has been completed. This then shows the user an empty view while RHP is dismissing.

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

We will change the state change here: to run after interactions, which will make it wait for the animation to be completed:

App/src/components/Lottie/index.tsx

Lines 82 to 88 in a4a344b

	// If the page navigates to another screen, the image fails to load, app is in background state, animation file isn't ready, or the splash screen isn't hidden yet,
	// we'll just render an empty view as the fallback to prevent
	// 1. memory leak, see issue: https://github.com/Expensify/App/issues/36645
	// 2. heavy rendering, see issues: https://github.com/Expensify/App/issues/34696 and https://github.com/Expensify/App/issues/47273
	// 3. lag on react navigation transitions, see issue: https://github.com/Expensify/App/issues/44812
	if (
	hasNavigatedAway ||

InteractionManager.runAfterInteractions(() => {
    setHasNavigatedAway(true);
});

Result

Screen.Recording.2024-09-26.at.2.36.22.AM.mov

[rushatgabhane]

@MonilBhavsar @neonbhai the reasons mentioned here suggest that we should do nothing. Or it may cause issues 1, 2, 3

But I guess that is only the case when the image hasn't loaded

App/src/components/Lottie/index.tsx

Lines 82 to 88 in a4a344b

	// If the page navigates to another screen, the image fails to load, app is in background state, animation file isn't ready, or the splash screen isn't hidden yet,
	// we'll just render an empty view as the fallback to prevent
	// 1. memory leak, see issue: https://github.com/Expensify/App/issues/36645
	// 2. heavy rendering, see issues: https://github.com/Expensify/App/issues/34696 and https://github.com/Expensify/App/issues/47273
	// 3. lag on react navigation transitions, see issue: https://github.com/Expensify/App/issues/44812
	if (
	hasNavigatedAway ||

[MonilBhavsar]

Since this was reported as a regression, may be it comes from #48040 🤔
Going to check

[MonilBhavsar]

Not reproducible after reverting #48040
@Krishna2323 @hungvu193 if you could please take a look

[hungvu193]

Not reproducible after reverting #48040 @Krishna2323 @hungvu193 if you could please take a look

No. It came from this one (#48444). It shows empty view while navigating away.

App/src/components/Lottie/index.tsx

Line 88 in 33818a9

hasNavigatedAway ||

Long story short, While working on #48040 with @Krishna2323, we found a bug, and it from PR of #47273, I commented there #47273 (comment). After that, the contributor of #47273 submitted another PR to fix the issue that we found which is #48444

[MonilBhavsar]

#48444 was deployed to production 2 weeks ago and this bug was only reproducible on staging. I don't think so it has caused this, unless I am missing something.

The bug stems from one of the PR from checklist #49662

[hungvu193]

#48444 was deployed to production 2 weeks ago and this bug was only reproducible on staging. I don't think so it has caused this, unless I am missing something

It's because we used static images for the BookTravel placeholder before. We switched to use LottieAnimation recently that's why you saw this issue. This issue will happen with any RHP that has Lottie animation because we hide them while navigating away to fix #47273
cc @QichenZhu and @suneox

[QichenZhu]

@hungvu193 Previously, playing animations in the background made the user interface unresponsive (#47273), so we stopped them after navigating away.

Now, after some updates in the app (possibly the RN upgrade), performance has improved. Although background animations still consume CPU, they no longer make the interface unresponsive.

If the high CPU usage is acceptable, we could allow animations to play in the background again.

cc @suneox

[suneox]

I commented there #47273 (comment).

@hungvu193 I have another comment to verify behavior on PR still works as expected after your comment

After that, the contributor of #47273 submitted another PR to fix the issue that we found

Nope, the PR is fix crashed issue

This issue will happen with any RHP that has Lottie animation because we hide them while navigating away to fix #47273

Before this PR, we didn’t have any use cases similar to this issue.

#48444 was deployed to production 2 weeks ago and this bug was only reproducible on staging. I don't think so it has caused this, unless I am missing something.

@MonilBhavsar Actually, I don’t think the PR from 2 weeks ago is a regression of the new feature because, at the time of the old PR, we didn’t have any context for the new feature. So, I believe this should be considered a new issue, and the scope of the old PR doesn’t cover the new one.

[suneox]

@QichenZhu I believe our PR shouldn’t cover the new feature introduced several weeks later, so you can go provide a new proposal for this issue.​

[hungvu193]

@suneox Hey I'm not trying to be picky here. This issue is clearly a regression from #48444.
We can reproduce this issue even when we reverted #48040. It happened with every single Lottie animation, but it can be easily reproducible with RHP.

Screen.Recording.2024-09-28.at.18.47.17.mov

Screen.Recording.2024-09-28.at.18.50.38.mov

That means, QA didn't find it during regression period of #48444. Since regression period was over for #48444. We can consider this as a new issue.

[QichenZhu]

@hungvu193 Yes, you're right that similar issues exist on other pages too. It wasn’t considered a problem before, probably because it’s not noticeable to the human eye. I have to use a slow motion camera to catch it.

Why is this issue noticeable on the travel page? Because the page slides out more softly. Below is a comparison video of the Preference and Travel pages at 16x slower speed.

animation.mp4

[suneox]

it’s not noticeable to the human eye, I have to use a slow motion camera to catch it.

Agreed, I only caught the issue on different pages by recording and replaying it. So, I think it should be handled as a new issue

@neonbhai proposal is straightforward for fixing the issue.

[MonilBhavsar]

Okay @suneox assigning you to the issue as a C+

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

Current assignee @suneox is eligible for the External assigner, not assigning anyone new.