[HOLD for payment 2023-08-24] [$1000] IOS - Chat - Focus is lost if user inserts emoji in edit mode using emoji picker

[kbecciv]

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. Launch App and open any chat
2. Post message in chat
3. Long tap on message and select 'Edit message'
4. Insert emoji in message using emoji picker

Expected Result:

Emoji inserted and focus is in composer

Actual Result:

Emoji inserted and focus is lost

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

Reproducible in staging?: Yes

Reproducible in production?: Yes

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

Bug6032214_iPad-emoji-insert-focus-lost.mp4

Bug6032214_iOS-emoji-insert-focus-lost.mp4

Expensify/Expensify Issue URL:

Issue reported by: Applause - Internal Team

Slack conversation:

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01186303df75f9ce05
• Upwork Job ID: 1681682595455336448
• Last Price Increase: 2023-07-19

[MelvinBot]

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

[MelvinBot]

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

[sophiepintoraetz]

Closing and adding to the tracking issue.

[sophiepintoraetz]

This might also be solved by this #15992

[lanitochka17]

Issue is reproducible in mWeb/Safari. Build 1.3.41.2

22542.mWeb.Lost.Focus.mp4

[mountiny]

@perunt Could this PR #18001 reintroduce this issue?

[perunt]

@mountiny, you referred to the same issue. Is it the correct link?

[mountiny]

@perunt Sorry, QA linked to this issue #18001

[melvin-bot]

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

[sophiepintoraetz]

@mountiny - are you talking about this PR? #22731

[mountiny]

wtf either I had a brain stroke or something was off with the copy past

#22542 this PR or #22529

[sophiepintoraetz]

All right, @mountiny so you're looking for @perunt to confirm whether #22542 this PR or #22529 introduced a regression that led to this issue being created?

[perunt]

In theory, it could be the case because I changed the method of copying the reference we use for this purpose. However, I did have a test for this in QA

Test Case 3: Focus Functionality
-Switch between the text box and the emoji picker multiple times, and verify that the focus is correctly switched each time.
-Verify that the text box regains focus when coming back from the emoji picker.

[kosmydel]

Hey, I'm from the SWM. I am going to investigate it.

I've quickly checked and the issue occurred before migration to the functional component as well (iOS).

Video before migration

before-migration.mp4

[kosmydel]

After short investigation I found out how it is done in the ReportActionCompose.

In this component, we call this.focus(true); when the modal is closed. The first param here means shouldelay. It adds a short delay before we call the focus function. More explanation in the comment:

// Keyboard is not opened after Emoji Picker is closed
// SetTimeout is used as a workaround
// https://github.com/react-native-modal/react-native-modal/issues/114
// We carefully choose a delay. 100ms is found enough for keyboard to open.
setTimeout(() => this.textInput.focus(), 100);

Using the same workaround in the ReportActionItemMessageEdit works:

Video

fix1.mp4

Should I create a PR for this?

[mountiny]

@kosmydel Sounds great, can you also confirm if this works if you open multiple edit messages?

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~01186303df75f9ce05

[situchan]

Coming from https://expensify.slack.com/archives/C02NK2DQWUX/p1689854072758689?thread_ts=1689852445.808529&cid=C02NK2DQWUX, I'd like to take this as C+

[melvin-bot]

📣 @situchan You have been assigned to this job!
Please apply to the Upwork job and leave a comment on the Github issue letting us know when we can expect a PR to be ready for review 🧑‍💻
Once you apply to this job, your Upwork ID will be stored and you will be automatically hired for future jobs!
Keep in mind: Code of Conduct | Contributing 📖

[ntdiary]

Hi, actually, the setTimeout workaround is unreliable on some devices. In other similar issues(#9252, #13922), I suggested using other ways to reliably open the keyboard, This is one of them:

• For Android app, we need to delay calling focus() until the window focus returns to the app, i.e. after receiving the AppState focus event.
• For IOS app and mobile web, we need to call focus in the onDismiss callback.

Finally, we can wrap them in a Promise to call, for example isReadyToFocus().then(() => input.focus()).
Just curious if we plan to continue using setTimeout for this issue, please feel free to let me know your thoughts. 🙂
@situchan @mountiny

[situchan]

@ntdiary your issue doesn't happen on main composer?

[situchan]

Here, we're cloning main composer behavior into edit composer as edit composer is also one of main components in the app and we're trying to make it much better as a quick solution.
The solution without setTimeout workaround can still be discussed but it takes time for approval.

[ntdiary]

@ntdiary your issue doesn't happen on main composer?

They happened on main composer and edit composer.

[sophiepintoraetz]

PR actively under review.

[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.54-13 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• Fix focus after picking an emoji in edit mode #23258

If no regressions arise, payment will be issued on 2023-08-24. 🎊

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:

• @kosmydel does not require payment (Contractor)
• @situchan requires payment

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:

• [@situchan] The PR that introduced the bug has been identified. Link to the PR:
• [@situchan] 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:
• [@situchan] 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:
• [@situchan] Determine if we should create a regression test for this bug.
• [@situchan] 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.
• [@sophiepintoraetz] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

[sophiepintoraetz]

Payouts due:

Issue Reporter: $250 NA
Contributor: $1000 @kosmydel
Contributor+: $1000 @situchan (offer sent - I'll release payment once the checklist is done!)

Eligible for 50% #urgency bonus? @mountiny - I don't think this one is eligible for a bonus, right? @kosmydel was assigned 20 Jul and the PR was merged on 11 Aug

[situchan]

No PR caused regression. This was default iOS behavior in RN modal.
The solution applied here was actually workaround which inherits main composer's setTimeout solution.
This workaround was completely removed in #13922 by fixing iOS native code in RN modal and I will add full regression test step in that issue.
So we can simply skip checklist here.

[mountiny]

Yeah no bonus here I imagine

[sophiepintoraetz]

Payments done!