[$250] mWeb - Reports - App crashes when using device´s back button after a search on "Reports"

[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.1.2-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
Email or phone of affected tester (no customers): [email protected]
Issue reported by: Applause Internal Team
Device used: Motorola MotoG60 - Android 12 - Chrome
App Component: Search

Action Performed:

1. Open the staging.new.expensify.com website.
2. Open "Reports" section.
3. Tap on "Search for something" and write any word.
4. Tap on the enter button on the keyboard.
5. Use device´s back button.
6. Check the website behaviour after this action.

Expected Result:

User should be able to return to expenses list after using device´s back button.

Actual Result:

App crashes when using device´s back button after triggering a search on "Reports" section.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug6748765_1740038286838!log.txt
https://github.com/user-attachments/assets/264fa9f1-3a31-4d19-9802-6e4617c02fb2

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021892972906702803151
• Upwork Job ID: 1892972906702803151
• Last Price Increase: 2025-03-07

Issue Owner

Current Issue Owner: @ikevin127

[melvin-bot]

Triggered auto assignment to @bfitzexpensify (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/~021892972906702803151

[melvin-bot]

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

[ikevin127]

🔄 This could be caused by the new search UI implementation:

• [Due for payment 2025-02-27] [$250] Update Search page to always show search input and type tabs at the top #52317
• Redesign search to always show search input(mobile + desktop). #55078 (first PR - was reverted)
• Add search input to mobile search page(with fixed performance) #56326 (this was the revert follow-up)
• a few other follow-up after the one above

cc @luacmartins @SzymczakJ Wdyt, is this issue related or it was happening before the new search UI implementation ?

Note: Also feels like there's 2 issues here, OP mentions that after you type something, you tap the soft keyboard Enter key then UI looks like no search was performed, whereas in my video below I actually tapped on the search suggestion and this way search was actually performed - but the navigation back bug / crash happens regardless of this.

I remember reviewing this issue where we did some work on the mWeb side for tapping search page soft keyboard Enter:

• [HOLD for payment 2025-01-17] [$250] Android/iOS- Highlighted search result go to search page rather that the highlighted detail page #53401

details where we clarified behaviour can be seen in this comment, but the new Search UI implementation might've removed that logic since search is not happening on the same page, resulting in the OP behaviour regarding search not actuallly being performed when tapping the soft keyboard Enter button.

🟢 I can consistently reproduce the issue, here's the video and error:

Android: mWeb	Error
screen-20250221-182536.mp4	Screen.Recording.2025-02-21.at.18.27.04.mov

[CyberAndrii]

I've looked into this a bit and the crash occurs when Animated.View has an exiting animation and contains a conditional child component. Simplified example:

<Animated.View exiting={FadeOutRight}>
    <ChildComponent />
    {condition && <ChildComponent />}
    <ChildComponent />
</Animated.View>

When I hardcode condition to true, it crashes with a slightly different message:

Failed to execute 'removeChild' on 'Node': The node to be removed is not a child of this node.

I think this happens because react-native-reanimated modifies the DOM directly, causing React to fail when applying changes from its virtual DOM. The crash no longer occurs when I comment out this lines.

As a workaround, we can wrap child elements with a View so that Animated.View doesn't have conditional child components:

<Animated.View exiting={FadeOutRight}>
    <View>
        <ChildComponent />
        {condition && <ChildComponent />}
        <ChildComponent />
    </View>
</Animated.View>

The original Animated.View code in Expensify/App is here, and child components are here.

BTW this issue is also reproducible in desktop Chrome with a narrow layout.

[luacmartins]

@tomekzaw I thought this was the issue we fixed last week. Could you take a look into this please?

[tomekzaw]

I've asked @m-bert from Reanimated team to take a closer look

[luacmartins]

Thank you! ❤

[ikevin127]

🔄 Not overdue, we're actively looking into this. More details in #57169 (comment).

[m-bert]

Hi!

@CyberAndrii, if you've managed to track down this issue, do you, by chance, have smaller reproduction that we could look at? Expensify is quite complex app and there are many things happening that make it harder to find what really causes this problem.

I agree that it might be the case that we modify DOM directly in Reanimated, but I don't understand why this issue happens only after modifying text input (if you go back without making any changes into it, app won't crash). Having simpler reproduction would definitely help 😅

[melvin-bot]

📣 @m-bert! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:

1. Make sure you've read and understood the contributing guidelines.
2. Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
3. Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
4. Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.
   
   Format:

Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>

[M00rish]

I tested this one a few days back and found the problem related with the addition of another freezeWrapper in SearchPage:

App/src/pages/Search/SearchPage.tsx

Line 55 in 4fe7c70

<FreezeWrapper>

[CyberAndrii]

Unfortunately, I don't have a smaller reproduction app. But yeah, another important detail is that this page is wrapped in a Freeze component which freezes it when navigating away. The crash occurs during unfreezing after navigating back.

App/src/libs/Navigation/AppNavigator/FreezeWrapper/index.tsx

Lines 7 to 26 in 4fe7c70

	function FreezeWrapper({children}: ChildrenProps) {
	const navigation = useNavigation();
	const currentRoute = useRoute();
	const [isScreenBlurred, setIsScreenBlurred] = useState(false);
	const [freezed, setFreezed] = useState(false);
	useEffect(() => {
	const unsubscribe = navigation.addListener('state', (e) => setIsScreenBlurred(getIsScreenBlurred(e.data.state, currentRoute.key)));
	return () => unsubscribe();
	}, [currentRoute.key, navigation]);
	// Decouple the Suspense render task so it won't be interrupted by React's concurrent mode
	// and stuck in an infinite loop
	useLayoutEffect(() => {
	setFreezed(isScreenBlurred);
	}, [isScreenBlurred]);
	return <Freeze freeze={freezed}>{children}</Freeze>;
	}

[m-bert]

I was able to reproduce it in Reanimated example app with react-freeze. However, I had to manually modify DOM during suspense to get this error, so there must be something else going on.

[melvin-bot]

@ikevin127 Whoops! This issue is 2 days overdue. Let's get this updated quick!

[ikevin127]

@luacmartins What do you think about @m-bert's solution and PR for a fix in react-native-reanimated ?

I'd say it looks promising for fixing this issue, but since to me the issue seems critical and merging the reanimated PR & updating E/App's reanimated version might take a while, what do you think about adding a patch to fix the issue in the meantime ?

Michał Bert should author the patch PR and I'll make sure to review it so we can fix this issue asap 👍

[luacmartins]

merging the reanimated PR & updating E/App's reanimated version might take a while, what do you think about adding a patch to fix the issue in the meantime ?

I'm not sure if it'll take that long, since the PR is already in review and SWM owns reanimated 😄 @m-bert @tomekzaw please correct me if I'm wrong and you also think we should apply a patch instead of waiting for the reanimated PR to be merged.

[melvin-bot]

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

[m-bert]

Hi!

I'm not sure if it'll take that long, since the PR is already in review and SWM owns reanimated 😄 @m-bert @tomekzaw please correct me if I'm wrong and you also think we should apply a patch instead of waiting for the reanimated PR to be merged.

I think it wouldn't take long to merge this PR, but I'm not sure about the release (maybe @tomekzaw could say more about it).

Also, it would be great if someone could test these changes in Expensify App. My test case in Reanimated works, but Expensify App still crashes at the same steps and at this point I'm not sure what actually breaks.

[luacmartins]

hmm so it seems like we still haven't found the root cause of the issue. We should keep investigating!

[ikevin127]

♻ Looking for a proposal that can identify the root cause and suggest a solution that fixes the issue.

[NJ-2020]

@ikevin127 Are you still able to reproduce the crash? I am not able to reproduce the crash on the latest main using both staging & non-staging servers

Android mWeb (staging server) ❌	Android mWeb (non-staging server) ❌
Screen.Recording.2025-03-05.at.20.50.55.mov	Screen.Recording.2025-03-05.at.20.50.16.mov

[melvin-bot]

@bfitzexpensify @ikevin127 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!

[m-bert]

@NJ-2020 it seems that it doesn't happen anymore. As far as I can see @Kicu removed FreezeWrapper in this commit, so it doesn't crash.

[NJ-2020]

Thanks

[ikevin127]

🟢 I confirm that the issue is not reproducible anymore in staging (v9.1.9-6) nor develop (v9.1.9-6) latest main.

[luacmartins]

Nice. I think we can close this issue then.

[melvin-bot]

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

[mvtglobally]

Issue not reproducible during KI retests. (First week)

[melvin-bot]

@ikevin127 Whoops! This issue is 2 days overdue. Let's get this updated quick!

[ikevin127]

Nice. I think we can close this issue then.

@luacmartins I agree!