[$500] iOS - Composer field loses focus & keypad dismissed when creating thread conversation

[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.36 Reproducible in staging?: Y Reproducible in production?: Y If this was caught during regression testing, add the test name, ID and link from TestRail: Exploratory around https://expensify.testrail.io/index.php?/tests/view/4280661&group_by=cases:section_id&group_order=asc&group_id=291937 Email or phone of affected tester (no customers): [email protected] Logs: https://stackoverflow.com/c/expensify/questions/4856 Expensify/Expensify Issue URL: Issue reported by: Applause - Internal Team Slack conversation:

Action Performed:

1. Launch New Expensify
2. Navigate to any conversation
3. Send message
4. Long press on message to open action menu
5. Select "Reply in thread" option
6. User redirected to new conversation page

Expected Result:

On step 6 - When user redirected to thread conversation, compose field should get focus & keypad to be triggered

Actual Result:

On step 6 - Composer field loses focus & keypad dismissed when creating thread conversation Note: When navigated to thread conversation, keypad appears for a moment, but collapses immediately

Workaround:

Unknown

Platforms:

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

• [ ] Android: Native
• [ ] Android: mWeb Chrome
• [x] iOS: Native
• [ ] iOS: mWeb Safari
• [ ] MacOS: Chrome / Safari
• [ ] MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

https://github.com/Expensify/App/assets/78819774/248a5bd3-4a65-4ae3-a23c-f4b951ea3b1a

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01c2a90f0a9fc124c8
• Upwork Job ID: 1754199374010019840
• Last Price Increase: 2024-02-04

[melvin-bot[bot]]

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

[melvin-bot[bot]]

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

[melvin-bot[bot]]

Triggered auto assignment to @puneetlath (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

[lanitochka17]

We think that this bug might be related to #vip-vsp CC @quinthar

[dhruv-dhola]

Step 1 Identify the Root Cause: Review the existing codebase related to the navigation and focus management. Check for asynchronous operations or race conditions that may cause the loss of focus.

Step2:-Ensure that the navigation to the new conversation page triggers the expected focus behavior on the compose field. Evaluate the sequence of events during the navigation process and make necessary adjustments.

Step3:-Implement a mechanism to explicitly manage the visibility of the keypad during the transition. Verify the timing of the keypad appearance and make sure it remains visible when creating a thread conversation.

[melvin-bot[bot]]

📣 @dhruv-dhola! 📣 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>

[ikevin127]

Proposal

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

When navigated to thread conversation, the parent report keyboard appears for a moment, but collapses immediately.

What is the root cause of that problem?

By design on native platforms we disable composer autofocus when navigating to a screen where composer is present as per this comment:

https://github.com/Expensify/App/blob/a1b33ef57861c5b35090c786bfce581f72843d38/src/pages/home/report/ReportActionCompose/ComposerWithSuggestions/ComposerWithSuggestions.js#L528-L530

The root cause of the problem we're trying to solve comes from the fact that when we press 'Reply in thread' and the context menu popover closes, composer focus is called from the hideContextMenu callback:

https://github.com/Expensify/App/blob/51f0a00b807e4801d43559000f11c51c54c90dda/src/pages/home/report/ContextMenu/ContextMenuActions.tsx#L192-L195

This causes the parent report keyboard to appear for a moment, but collapse immediately once navigated to the thread since on native we don't autofocus the composer when navigated to a screen, by design.

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

A sleek solution for this issue would be to create a lib for native only which will use a promise that will resolve with a timeout of 300ms -> calling composer blur, then -> navigate to the thread.

const promise = new Promise(resolve => { 
    setTimeout(() => {
        resolve();
    }, CONST.ANIMATED_TRANSITION);
});

promise.then(() => {
    ReportActionComposeFocusManager.composerRef.current?.blur();
}).then(() => {
    Report.navigateToAndOpenChildReport(reportAction?.childReportID ?? '0', reportAction, reportID);
});

The index.native.ts will include the promise delayed blur / navigation logic whereas the index.ts will simply call the same callback as currently (unchanged). We will call this lib function inside the 'Reply in thread''s hideContextMenu callback mentioned above in the RCA.

Videos

iOS: Native

Before	After

[dhruv-dhola]

so in the above video i see there if you open keypad in conversation screen and goes to reply thread then first it close that keypad and again open it. so may be when user navigate to reply thread screen it may be triggered old reference of the keypad first and the process of navigation to one screen to another and keypad focus process happens at same time so i suggest that write code for this block in simultaneously way but there is slightly difference in timing which is minor 2to3 sec.

[mollfpr]

@dhruv-dhola Please post a proposal using the PROPOSAL_TEMPLATE, thanks!

---

instead of going back to the parent report, the user is havigated to home

@ikevin127 We can ignore the above issue, it might be related to the big app structure changes lately.

---

https://github.com/Expensify/App/blob/a1b33ef57861c5b35090c786bfce581f72843d38/src/pages/home/report/ReportActionCompose/ComposerWithSuggestions/ComposerWithSuggestions.js#L528-L531

I think this is not a bug. The comment stated that autofocus on the native is creating a UX problem.

[ikevin127]

@mollfpr If I understand correctly - what we want here is to not see the parent report keyboard collapse after we're navigated to the thread, but before that.

When navigated to thread conversation, keypad appears for a moment, but collapses immediately

Meaning we just fix this part of the actual result instead of actually doing what the expected result states ?

Updated proposal

• changed RCA and solution + videos according to different expected result

My updated solution would be a temporary workaround - as there are lots of similar keyboard / focus related issues that will be solved once this PR will be merged https://github.com/Expensify/App/pull/29199.

I don't think it's worth extracting logic from that PR and adding it here as a targeted solution for our specific case.

[mollfpr]

I would say we can hold for the sake of https://github.com/Expensify/App/pull/29199 and I don't think we can accept a workaround for now.

[melvin-bot[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[bot]]

@puneetlath, @mollfpr Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[mollfpr]

Not overdue.

[ikevin127]

More context regarding a possible resolve for the mentioned hold, in this Slack thread: https://expensify.slack.com/archives/C01GTK53T8Q/p1708525183773549

[puneetlath]

Still on hold.

[puneetlath]

Still on hold.

[puneetlath]

I don't think this is a bug anymore. I just tested it and the keyboard doesn't show at all, even momentarily. But I think that's fine. So I'm going to close the issue. Let me know if I've misunderstood or if you disagree!