[HOLD #16078][$2000] suggestion for Emoji remains even after sending message

[kavimuru]

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. Go to any chat
2. Type for any emiji ( do not select suggested emoji)
3. Send message

Expected Result:

Suggested emoji should be removed after sending the message

Actual Result:

Emoiji suggestions shows

Workaround:

unknown

Platforms:

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

• [ ] Android / native
• [x] Android / Chrome
• [ ] iOS / native
• [ ] iOS / Safari
• [x] MacOS / Chrome / Safari
• [ ] MacOS / Desktop

Version Number: 1.2.92-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 Notes/Photos/Videos:

https://user-images.githubusercontent.com/43996225/224875615-cecd9a1d-1424-46f2-b08e-51a0f88da5a2.mp4

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

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01eccf0dd16e54ab9d
• Upwork Job ID: 1643225880592248832
• Last Price Increase: 2023-04-24

[MelvinBot]

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

[MelvinBot]

Bug0 Triage Checklist (Main S/O)

• [x] This "bug" occurs on a supported platform (ensure Platforms in OP are ✅)
• [x] 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
• [x] 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

[MelvinBot]

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

[MelvinBot]

@miljakljajic Still overdue 6 days?! Let's take care of this!

[miljakljajic]

I am not able to reproduce this - I believe it may have been resolved while I was OOO.

[tienifr]

@miljakljajic I still can reproduce on staging web

https://user-images.githubusercontent.com/113963320/227412543-784eb91e-68eb-483b-80c9-19ca1454e180.mov

[tienifr]

It seems @miljakljajic is not available during this time. @kavimuru Could you reproduce this issue?

[kadiealexander]

This has also been reported here on mac web (chrome), but I was unable to reproduce it on v1.2.92-0 on the staging version. @gadhiyamanan, before this one gets reopened, could you please test on the app version v1.2.92-0 and confirm it's reproducible?

[gadhiyamanan]

@kadiealexander I can reproduce it with the latest version v1.2.92-0

[Pujan92]

This has also been reported here on mac web (chrome), but I was unable to reproduce it on v1.2.92-0 on the staging version. @gadhiyamanan, before this one gets reopened, could you please test on the app version v1.2.92-0 and confirm it's reproducible?

@kadiealexander assuming you might have used enter to send message but to reproduce you need to click on send button.

[jliexpensify]

Ok, tested on Pixel 3a (v 92-0) and I can reproduce:

[jliexpensify]

to reproduce you need to click on send button.

Yep, that's what I did - clicked on the button

[kadiealexander]

Thanks for that tip @Pujan92, I was able to repro on mac web chrome:

https://user-images.githubusercontent.com/59587260/228722334-b51d2bf5-f361-4685-820a-8d78ea628eb0.mp4

[miljakljajic]

Thank you for reproducing! Do we think this could be worked on externally? Adding engineering label to confirm

[MelvinBot]

Triggered auto assignment to @MonilBhavsar (Engineering), see https://stackoverflow.com/c/expensify/questions/4319 for more details.

[MelvinBot]

@miljakljajic @MonilBhavsar this issue is now 3 weeks old. There is one more week left before this issue breaks WAQ. What needs to happen to get a PR in review this week? Please create a thread in #expensify-open-source to discuss. Thanks!

[MonilBhavsar]

I am able to reproduce. Can be worked externally

[MelvinBot]

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

[MelvinBot]

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

[Pujan92]

Proposal

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

Emoji suggestions still shows after send button click

What is the root cause of that problem?

On submitting the comment we are not resetting the emoji suggestions which causes the suggestions are still showing after send button click.

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

We need to call this.resetSuggestedEmojis() inside the prepareCommentAndResetComposer after resetting the comment here. https://github.com/Expensify/App/blob/8a1510373598807a4ea6c5049f2a3121dfbd9215/src/pages/home/report/ReportActionCompose.js#L625-L633

[MelvinBot]

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

[MelvinBot]

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

[situchan]

Proposal

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

Emoji suggestion popover still remains after clearing composer input programatically

What is the root cause of that problem?

onSelectionChange event is not called when input is cleared programmatically. We calculate emoji suggestion visibility in this function. So when send message, input cleared but popover visibility is not re-calculated.

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

This is web issue. Works fine on native (onSelectionChange is called and selection is updated to {start: 0, end: 0}). So the ideal solution is to fix this selection issue on web because after sending message, selection value will be staled until user focus on input again or type anything. Solution1: make onSelectionChange work when clear input in upsream repo Solution2: call onSelectionChange manually when input is cleared Solution3: manually call resetSuggestedEmojis after reset composer but this is workaround because selection still remains

[dukenv0307]

Proposal

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

Emoji suggestions still remain after sending a message

What is the root cause of that problem?

We have a logic to resetSuggestedEmojis when entering escape from the keyboard, but we don't do the same when clicking the button so that the emoji suggestions still remain after the button is clicked

This issue is fixed in native because after clicking the send button, onSelectionChange is triggered so that it will re-calculate the emoji suggestion with the empty composer (because the composer is cleared after clicking the send button).

The current flow in native: Click send button > onClear is triggered (the emoji suggestion still remains) > send API > onSelectionChange is triggered (the emoji suggestion disappears). See the below video

https://user-images.githubusercontent.com/129500732/229962804-4289b210-a986-469a-8535-d3cd088b85d9.mp4

We can see that the suggestion doesn't disappear immediately after send button is clicked. I see that if we close the suggestion emoji when onSelectionChange is not suitable and the fix on native currently is a workaround

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

 onClear={() => {
                                                console.log('CLEAR');    // THIS IS LOG IN THE ABOVE VIDEO
                                                this.resetSuggestedEmojis();    // ADD HERE
                                                this.setTextInputShouldClear(false);
                                            }}

We can call this.resetSuggestedEmojis() when onClear is triggered

What alternative solutions did you explore? (Optional)

In ReportActionCompose.js, we should add logic to reset the emoji suggestion by adding resetSuggestedEmojis() function inside prepareCommentAndResetComposer() function. Like this

prepareCommentAndResetComposer() {
        const trimmedComment = this.comment.trim();

        // Don't submit empty comments or comments that exceed the character limit
        if (this.state.isCommentEmpty || ReportUtils.getCommentLength(trimmedComment) > CONST.MAX_COMMENT_LENGTH) {
            return '';
        }
        this.resetSuggestedEmojis();    // ADD HERE
        this.updateComment('');
        this.setTextInputShouldClear(true);
        if (this.props.isComposerFullSize) {
            Report.setIsComposerFullSize(this.props.reportID, false);
        }
        this.setState({isFullComposerAvailable: false});

        return trimmedComment;
    }

Result

https://user-images.githubusercontent.com/129500732/229809240-bf380fec-0618-4f90-a2cb-721d8a019d15.mov

[s77rt]

@Pujan92 Thanks for the proposal. I'm afraid your proposal is not eligible for review.

https://github.com/Expensify/App/blob/main/contributingGuides/CONTRIBUTING.md#propose-a-solution-for-the-job

Do not propose solutions to jobs until the Help Wanted label has been applied. Any proposals submitted before these labels are added will not be reviewed.

[s77rt]

@situchan Thanks for the proposal. Your RCA is correct. I think we are looking for an upstream fix here. Are you working on a PR for that or can you elaborate your suggested upstream changes?

[s77rt]

@dukenv0307 Thanks for the proposal. I don't think the RCA is correct as it does not explain why the bug only occurs on Web and not Native.

[dukenv0307]

@s77rt I just updated my proposal

PROPOSAL

Updated

[s77rt]

@dukenv0307 Thanks for the update. I think what you are suggesting is more like an improvement and does not fix the root cause. I think we should still fix the stale selection on RNW.

[s77rt]

Not overdue. We narrowed the bug to RNW and we are looking for an upstream fix (fix stale selection on RNW).

[MelvinBot]

@s77rt @miljakljajic @MonilBhavsar this issue is now 4 weeks old and preventing us from maintaining WAQ, can you:

• Decide whether any proposals currently meet our guidelines and can be approved as-is today
• If no proposals meet that standard, please take this issue internal and treat it as one of your highest priorities
• If you have any questions, don't hesitate to start a discussion in #expensify-open-source

Thanks!

[MelvinBot]

Current assignee @s77rt is eligible for the Internal assigner, not assigning anyone new.

[MonilBhavsar]

@s77rt could you please provide more details on this https://github.com/Expensify/App/issues/15934#issuecomment-1502086640

[s77rt]

@MonilBhavsar Check https://snack.expo.dev/JGFbUc_KU?platform=android

On Android:

1. Focus Input
2. Click on Fill, notice the selection changes to 5
3. Click on Clear, notice the selection changes to 0

On Web:

1. Focus Input
2. Click on Fill, notice the selection changes to 5
3. Click on Clear, notice the selection is stale still showing 5 instead of 0

iOS is having a different behavior, on the Expo Snack it's not working but on E/App it's working, this may be due to other factors. For simplicity let's focus on matching Web behavior with Android behavior.

[MelvinBot]

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

[MelvinBot]

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

[MelvinBot]

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

[MonilBhavsar]

Thanks for the explanation! I made it external again. Are we still waiting for proposals for upstream fix or it is already being worked on?

[MelvinBot]

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

[s77rt]

@MonilBhavsar We are still waiting for proposals.

[alitoshmatov]

Proposal

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

suggestion for Emoji remains even after sending message

What is the root cause of that problem?

To be more clear, the issue is originating from onMouseDown event handler. When button view is clicked, we are calling https://github.com/Expensify/App/blob/ee3a27e9de22ca519c0ca6632a2dfee4246d4966/src/pages/home/report/ReportActionCompose/index.js#L924 to keep focus on composer. Although it is keeping focus on composer it is not registering cursor change and not firing onSelectionChange.
If we try the same thing in react it self it works as expected - https://codesandbox.io/s/quizzical-sutherland-4uwx4?file=/src/index.js

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

After a long investigation, it looks like it is not possible to fix it in upstream. Basically, this is coming down to how react native handles events, and react native web's extension on this usage. They are using responder system to manage mouse events. One of the side effect is onMouseDown event is not passed to dom itself unlike react which passes, and they are handling preventDefault() differently. Even passing the event to dom manually won't work. There are a lot of things going on in react-native and react-native-web to intercept this events and to handle them.

Is it possible to fix responder it self? Well, responder itself is looking pretty complex and has a lot of moving parts, also it is responsible for mainly handling touch based interactions in mobile platforms. One small change might cause whole another wave of side effects which is hard to catch and effect entire app. And I think that fix itself would be some sort of workaround.

The most optimal solution is going to be manually resetting selection when input gets cleared. This solution might look a hack if we treat not calling selectionChange when input gets cleared as bug, which is arguable. If we use javascript itself it will only call onSelect if there is an actual selection - https://codesandbox.io/s/goofy-goldberg-52lys?file=/src/index.js

P. S. According to react-native-web onSelectionChange is directly corresponding to onSelect attribute.

This what the best conclusion I have drawn to summarize my research but still if you have any questions, I am here to answer

What alternative solutions did you explore? (Optional)

[s77rt]

@alitoshmatov Thanks for the proposal. At first, I thought this is related to onMouseDown too, but the fact that the "Fill" button works https://codesandbox.io/s/cocky-grass-xvxqgr tells us there is more. On Web (HTML5) the input's onSelect handler does not track the cursor position. React seems to be implementing its own cursor-tracking logic and that logic is missing the case where the input is programmatically cleared. I think we agree that the bug is even at a lower level which react itself.

That being said I think we are narrowing the bug to react's SelectEventPlugin.

[alitoshmatov]

@s77rt I think you missed that onMouseDown event is applied to outer div and "Fill" button is also inside this div. That's why it is working. And that is expected behavior. Thus, bug is not in react itself.

Correct me if I missed something

[s77rt]

@alitoshmatov But the "Clear" button has the same circumstances as "Fill". Yet "Clear" does not work while "Fill" works. Check the sent codesandbox https://codesandbox.io/s/cocky-grass-xvxqgr

https://user-images.githubusercontent.com/16493223/232334181-9b13a046-4066-41c6-bd2c-cfe32c7dc961.mp4

[alitoshmatov]

@s77rt So there has been a bit misunderstanding between us, and just to make this issue more complex here is a new finding 😅. I have been using firefox and in the example you provided both buttons, including "clear" will reset selection. But in chrome as you said "clear" button is not working

[s77rt]

@alitoshmatov That's interesting. I have tried on Webkit/Safari and the issue is not reproducible there. So I think this is probably a bug in Chrome?

[alitoshmatov]

@s77rt It might be. But still in react native it is not working in both browsers

[s77rt]

@alitoshmatov Right, but we can ignore Firefox as it's not officially supported. On WebKit that works.

https://user-images.githubusercontent.com/16493223/232337525-3ce5cdfe-26c9-4496-9f73-2643952af3dc.mp4

[alitoshmatov]

@s77rt Yeah, this issue in expensify app is not reproducible in safari.

I am confused

[s77rt]

Right, I still think we should investigate why SelectEventPlugin fails on Chrome. Then we can decide if the bug can be fixed on the plugin or it's something related to Chrome.