[HOLD #31705][$500] Desktop - Compose Box - When the app reloads, "Write something..." text and the cursor moves up

[lanitochka17]

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: 1.4.2-0
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 Team
Slack conversation:

Action Performed:

1. Open New Expensify app
2. Navigate to any conversation
3. Reload the application(CMD+R)
4. Click on "Go back to home page" (if required)

Expected Result:

When the application reloads, "Write something..." text and the cursor should be centered in the Compose Box

Actual Result:

When the application reloads, "Write something..." text and the cursor moves up in the Compose Box

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

Bug6287583_1700678534952.Recording__762.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~014ec0e25eb59f5d17
• Upwork Job ID: 1727422130676625408
• Last Price Increase: 2023-11-29

[melvin-bot]

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

[melvin-bot]

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

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

[erquhart]

Not seeing this in dev.

[mkhutornyi]

Proposal

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

Composer style is broken when navigate back from not found page after reload

What is the root cause of that problem?

App/src/components/Composer/index.js

Line 348 in 6aa94c9

const computedNumberOfLines = ComposerUtils.getNumberOfLines(lineHeight, paddingTopAndBottom, textInput.current.scrollHeight, maxLines);

textInput.current.scrollHeight is set to 0 so this function returns 0 which makes numberOfLines also 0 and thus rows prop value

App/src/components/Composer/index.js

Line 451 in 6aa94c9

rows={numberOfLines}

I think this is race condition. scroll height is 0 because rows is 0

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

Pass rows value always bigger than 0
So either set default value of numberOfLines to 1 here or update this line to rows={numberOfLines || 1}

[sakluger]

First of all, why does reloading the page take you to the "Hmm...it's not here" page? That seems like a bigger bug. Does that only happen on Desktop or on other platforms too?

For the compose box spacing issue, @mkhutornyi do you have any ideas why it's only happening on Desktop and not on other platforms?

[mkhutornyi]

First of all, why does reloading the page take you to the "Hmm...it's not here" page? That seems like a bigger bug.

It's known bug - #28495, #31592

Cursor issue happens on web as well.

Here's simple repro step:

1. Navigate to any url that doesn't exist i.e. https://staging.new.expensify.com/test
2. Close not found page

[melvin-bot]

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

[melvin-bot]

@sakluger, @aimane-chnaif Whoops! This issue is 2 days overdue. Let's get this updated quick!

[sakluger]

Thanks for sharing those other issues! I looked but couldn't find them.

@aimane-chnaif what do you think about @mkhutornyi's proposed solution?

[aimane-chnaif]

set default value of numberOfLines to 1 here

This solution sounds good.

@bernhardoj did you have any reason for setting this value to 0, not 1?

[bernhardoj]

The numberOfLines before is undefined and 0 is the equivalent of it.

We had discussed it before here whether to set it as 0 or 1.

[aimane-chnaif]

The numberOfLines before is undefined and 0 is the equivalent of it.

We had discussed it before here whether to set it as 0 or 1.

Ah yes, I remember. But I don't see any difference between 0 or 1 even when multiline

[bernhardoj]

But I don't see any difference between 0 or 1 even when multiline

I think we should look at the PR that implemented it. This is the commit that changed it from 1 to undefined.

But I think changing it to 1 (or any other value) is not the solution here. I checked that the issue is the numberOfLines calculation is always 0. If the composer has a draft with multiline text, having a 1 numberOfLines will only show the 1st line of the text (haven't tested it yet because the draft is always cleared after refresh, another bug?).

[aimane-chnaif]

because the draft is always cleared after refresh

This is known bug - #31705

Maybe we can put on hold a bit since we cannot test all cases without fixing that bug

[bernhardoj]

While waiting for the draft issue, here is my proposal

Proposal

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

Open a not found page and then press back will show a composer with 2 lines.

What is the root cause of that problem?

When we open a not found page (e.g. /asd), the nav stack looks like this:
[LHN, ReportScreen, Not Found]

In react-navigation, a previous not focused screen will have a display: none style applied to it, in our case, the ReportScreen is not focused, therefore a display: none is applied to it (except the navigator has presentation: 'transparentModal', for example, RHP). Because the display is none, getting the scrollHeight of the composer input will always return 0 (ref).

And so the number of lines calculation always returns 0. A number of lines/rows is 0 is the same as not setting the rows property to the textarea and by default, it will have 2 lines.

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

One trick to keep the report screen displayed is by setting the not found page screen presentation to transparentModal.

App/src/libs/Navigation/AppNavigator/AuthScreens.js

Lines 327 to 331 in 2e8de3f

	<RootStack.Screen
	name={SCREENS.NOT_FOUND}
	options={screenOptions.fullScreen}
	component={NotFoundPage}
	/>

options={{
    ...screenOptions.fullScreen,
    presentation: 'transparentModal',
}}

And because we made it transparent, we must set a background color for not found page.

<ScreenWrapper testID={NotFoundPage.displayName} style={[styles.appBG]}>

What alternative solutions did you explore? (Optional)

Re-calculate the number of lines every time the report screen gets focused.

In Composer/index.js

useFocusEffect(useCallback(() => {
    const timeout = setTimeout(() => updateNumberOfLines(), 300);
    return () => clearTimeout(timeout);
}, []));

Without the delay, the display is still none even after when it gets focused

If there is a not found page, don't add a report screen to the navigation.

In CustomRouter.js

+const isNotFoundPageInState = (state) => _.find(state.routes, (r) => r.name === SCREENS.NOT_FOUND)

-if (!isAtLeastOneCentralPaneNavigatorInState(partialState) && !options.getIsSmallScreenWidth()) {
+if (!isAtLeastOneCentralPaneNavigatorInState(partialState) && !options.getIsSmallScreenWidth() && !isNotFoundPageInState(partialState)) {
    addCentralPaneNavigatorRoute(partialState);

[sakluger]

Still on hold for #31705.

[sakluger]

Still on hold for #31705.

[aimane-chnaif]

The holding issue is on hold for #32461

[sakluger]

Still on hold.

[sakluger]

#32461 is still a draft and it looks like a new PR has been raised for that same issue: #35449. Either way, we're still on hold here.

[sakluger]

Still on hold for #35449.

[sakluger]

The holding PR is merged and deployed, and I can't seem to reproduce this issue. I think it's fixed!

@aimane-chnaif I'm pretty sure no payment is due on this one, can you please confirm before I close the issue?

[aimane-chnaif]

The bug is not reproducible because of recent regression (maybe navigation refactor) which reloads report screen every time after navigating back.
The root cause is not fixed yet.

[aimane-chnaif]

Let's close this for now. I will bump here to reopen when this is reproducible again in the future.

[sakluger]

Sounds good. If we need to reopen this issue in the future, can you please bump in Slack instead? I sometimes miss notifications related to closed GH issues.