[HOLD for payment 2023-09-07] [$1000] Web - Composer out focus when the thread has many messages

[kbecciv]

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

---

Action Performed:

1. Open any report
2. Chat a message
3. Go reply in thread
4. Click edit parent message
5. Click composer and send many messages (about > 22 messages), Observe that composer is out of focus and switches to focus edit parent message

Expected Result:

Composer doesn't lose focus

Actual Result:

Observe that composer is out of focus and switches to focus edit parent message after send many message

Workaround:

Unknown

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.47.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
Notes/Photos/Videos: Any additional supporting documentation

Screen.Recording.2023-07-29.at.13.30.43.mov

Recording.4004.mp4

Expensify/Expensify Issue URL:
Issue reported by: @namhihi237
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1690612204876679

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~019d68a31c68ab4865
• Upwork Job ID: 1685790256290459648
• Last Price Increase: 2023-08-06
• Automatic offers:
• mollfpr | Reviewer | 26033382
• tienifr | Contributor | 26033383
• namhihi237 | Reporter | 26033386

[melvin-bot]

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

[jliexpensify]

I can somewhat repro this, but not reliably.

I did discover an additional issue related to the composer and the Edit function:

1. Start chat, type something and click on "Thread"
2. Click on "Edit" on original word/message
3. Start typing multiple letters in thread
4. After ~ 12 (?) letters in-thread, notice that the compose has been edited with the most recent letter.

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

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

[jliexpensify]

Hi @mollfpr - given this is a composer issue, I also notice this GH was recently opened (#23898). Do you think the root causes are similar?

[tienifr]

Proposal

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

Observe that composer is out of focus and switches to focus edit parent message after send many message

What is the root cause of that problem?

It's here, we're focusing the "edit message" input in first render (and whenever isDraftEmpty change), regardless of the previous value of the draft message.

So when the page reloads, or when the message edit input goes out of view and is rerendered again, it will automatically gain focus (even though the isDraftEmpty status does not change)

This is a regression after the functional component refactor.

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

We can use isFirstRender similar to here and early return in this block if it's the first render:

if (isFirstRender.current) {
    isFirstRender.current = false;
    return;
}

aka we only focus the input if the isDraftEmpty status changes, not whenever that component remounts.

Since this first render logic is used quite commonly now, we can create a dedicated hook for it, for better reuse.

What alternative solutions did you explore? (Optional)

Another solution is to use usePrevious to get the value of the previous draft message and only focus the edit input if previous draft message is empty and current draft message is not empty, similar to the logic before the functional component refactor.

const prevDraftMessage = usePrevious(props.draftMessage);

useEffect(() => {
    if (prevDraftMessage || !props.draftMessage) {
        return;
    }

    focusTextInputAfterAnimation(textInputRef.current, 100);
}, [prevDraftMessage, props.draftMessage]);

[Update: the below was already fixed]
Also there's another bug in usePrevious where the initial value of it is always undefined (even though the observed value is never undefined.
We need to change this line https://github.com/Expensify/App/blob/09cf7dc362d78781d2efd734018780caa634a126/src/hooks/usePrevious.js#L10C26-L10C26 to const ref = useRef(value); to set the initial value of the ref correctly. Or we can add another initialValue as a 2nd param for usePrevious, and use it to set the initial value for the usePrevious in this case.