[HOLD for payment 2023-10-16] [$500] Report screen becomes empty when resizing to big size from LHN

[kavimuru]

If you haven’t already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!

---

Action Performed:

1. Resize the app to small width.
2. Navigate to LHN.
3. Resize again to larger width

Expected Result:

The report screen should be present on the right

Actual Result:

There is no report screen on the right.

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.74-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

20230927_201827.mp4

Screen.Recording.2023-09-25.at.11.30.00.PM.1.mov

Expensify/Expensify Issue URL:
Issue reported by: @esh-g
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1695664942781769
View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~0117356277518975bf
• Upwork Job ID: 1707142377110151168
• Last Price Increase: 2023-09-27
• Automatic offers:
• tienifr | Contributor | 26975213
• esh-g | Reporter | 26975214

[melvin-bot]

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

[melvin-bot]

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

[allroundexperts]

Proposal

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

Report screen becomes empty when resizing to big size from small size while on LHN.

What is the root cause of that problem?

The root cause of the issue is that getRehydratedState function here gets executed before the ResponsiveStackNavigator component re-renders. This causes the value of ref of the isSmallScreenWidth to always lag one render behind. Thus, the condition here does not execute correctly.

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

Instead of passing in a getIsSmallScreenWidth function here, we should replace this with the following:

const isSmallScreen = Dimensions.get('screen').width <= variables.extraSmallMobileResponsiveHeightBreakpoint;
            // Make sure that there is at least one CentralPaneNavigator (ReportScreen by default) in the state if this is a wide layout
            if (!isAtLeastOneCentralPaneNavigatorInState(partialState) && !isSmallScreen) {

What alternative solutions did you explore? (Optional)

None

[tsa321]

Cannot reproduce in version v1.3.72-5.

[tienifr]

Proposal

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

There is no report screen on the right.

What is the root cause of that problem?

We're using debounce for the window dimensions in withWindowDimensions here. This leads to the isSmallScreenWidth of withWindowDimensions being updated 300ms after the window dimensions change (for performance reasons), which is after the getRehydratedState here is called, causing getRehydratedState to get the stale value of isSmallScreenWidth and renders incorrectly.

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

Since we want to retrieve the latest value of isSmallScreenWidth in getRehydratedState, we should use the useWindowDimensions which is an one-off hook that provides the same correct isSmallScreenWidth value.

1. Replace this line with

const {isSmallScreenWidth} = useWindowDimensions();

const isSmallScreenWidthRef = useRef(isSmallScreenWidth);

isSmallScreenWidthRef.current = isSmallScreenWidth;

2. And remove this line

What alternative solutions did you explore? (Optional)

We can calculate the isSmallScreenWidth again in the getRehydratedState using Dimensions, but this unnecessarily duplicates the calculation logic, so I prefer to reuse the hook that we already have.

[narefyev91]

Proposal from @tienifr looks good to me #28354 (comment)
To be sure that rehydrate state will be up-to-date we should use direct hook for getting isSmallScreenWidth
🎀 👀 🎀 C+ reviewed

[melvin-bot]

Triggered auto assignment to @arosiclair, see https://stackoverflow.com/c/expensify/questions/7972 for more details.

[allroundexperts]

@narefyev91 Are you sure we want to go via this route?

We might want to debounce useWindowDimensions as well in the future for performance reasons. Doing so will re-introduce this bug. Adding the small screen check directly here as shown in my proposal is a more fail proof solution.

Also, the above approach has an added advantage in the sense that ResponsiveStackNavigator would get rid of the screen size dependency (and the ref + extra renders which comes with it) altogether.

@arosiclair Would be awesome to get your opinion as well before we proceed.

[narefyev91]

@allroundexperts Hey! debounce was added only for one particular case - to prevent crash during fast resizing and remove loading indicator #26071 - and i think that fix was a hack. Using debounce in useEffect may lead to unpredictable results - like even fetching not correct size. BTW now we planning to move away from HOC withWindowDimensions - and we can use direct hook without listening for changes in useEffect inside HOC.
Also i checked solution from @tienifr for current issue and for issue with resizing image:

8mb.video-Bx1-WZ2rWPv6.mp4

On the other hand - @allroundexperts solution is working but breaking go back logic

Screen.Recording.2023-09-29.at.10.20.52.mov

Current issue is a regression from adding debounce to track resize changes - and using direct size from useWindowDimensions is a correct workflow.

cc @arosiclair

[allroundexperts]

Thanks for the detailed response @narefyev91. That's a nice catch. Let's go with @tienifr's solution!

[melvin-bot]

📣 @tienifr 🎉 An offer has been automatically sent to your Upwork account for the Contributor role 🎉 Thanks for contributing to the Expensify app!

Offer link
Upwork job
Please accept the offer and leave a comment on the Github issue letting us know when we can expect a PR to be ready for review 🧑‍💻
Keep in mind: Code of Conduct | Contributing 📖

[melvin-bot]

📣 @esh-g 🎉 An offer has been automatically sent to your Upwork account for the Reporter role 🎉 Thanks for contributing to the Expensify app!

Offer link
Upwork job

[melvin-bot]

@arosiclair, @narefyev91, @tienifr Whoops! This issue is 2 days overdue. Let's get this updated quick!

[arosiclair]

Not sure why Bug was not applied and we went straight to External

[melvin-bot]

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

[melvin-bot]

Based on my calculations, the pull request did not get merged within 3 working days of assignment. Please, check out my computations here:

• when @tienifr got assigned: 2023-10-02 07:58:37 Z
• when the PR got merged: 2023-10-05 08:21:47 UTC
• days elapsed: 3

On to the next one 🚀

[tienifr]

@arosiclair Is it eligible for 50% bonus because I and @narefyev91 finished work very early?

[arosiclair]

@arosiclair Is it eligible for 50% bonus because I and @narefyev91 finished work very early?

I think we usually count any time for review so probably no but I'm not sure really. @zanyrenney ^

[jasperhuangg]

This issue is still present on Web/Desktop on staging, @tienifr please look into this.

[melvin-bot]

Reviewing label has been removed, please complete the "BugZero Checklist".

[melvin-bot]

The solution for this issue has been 🚀 deployed to production 🚀 in version 1.3.79-5 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• fix: 28354 Report screen becomes empty when resizing to big size from LHN #28683

If no regressions arise, payment will be issued on 2023-10-16. 🎊

After the hold period is over and BZ checklist items are completed, please complete any of the applicable payments for this issue, and check them off once done.

• External issue reporter
• Contributor that fixed the issue
• Contributor+ that helped on the issue and/or PR

For reference, here are some details about the assignees on this issue:

• @narefyev91 does not require payment (Contractor)
• @tienifr requires payment offer (Contributor)
• @esh-g requires payment offer (Reporter)

As a reminder, here are the bonuses/penalties that should be applied for any External issue:

• Merged PR within 3 business days of assignment - 50% bonus
• Merged PR more than 9 business days after assignment - 50% penalty

[melvin-bot]

BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:

• [@narefyev91] The PR that introduced the bug has been identified. Link to the PR:
• [@narefyev91] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment:
• [@narefyev91] A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion:
• [@narefyev91] Determine if we should create a regression test for this bug.
• [@narefyev91] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.
• [@zanyrenney] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

[zanyrenney]

@arosiclair @tienifr #28354 (comment) based on this comment, it is not eligible for the urgency bonus.

the pull request did not get merged within 3 working days of assignment

[zanyrenney]

payment summary

@narefyev91 does not require payment (Contractor)
@tienifr requires payment offer (Contributor) - paid $500
@esh-g requires payment offer (Reporter) paid $50