[$500] Emojis - "No results found" message appears when select "Hand" from keyboard suggestion

[izarutskaya]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com 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. Open any conversation
3. Navigate to emoji picker
4. Type "hand" into search bar
5. Choose emoji from keyboard suggestion

Expected Result:

Selected emoji should be applied and not error messages should appear

Actual Result:

"No results found" message appears when select "Hand" from keyboard suggestion

Workaround:

Unknown

Platforms:

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

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

Screenshots/Videos

https://github.com/Expensify/App/assets/115492554/5857c889-495f-489b-8814-b49deffe0dcc

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01018ef056ade09956
• Upwork Job ID: 1727652489576235008
• Last Price Increase: 2023-12-07

[melvin-bot[bot]]

Job added to Upwork: https://www.upwork.com/jobs/~01018ef056ade09956

[melvin-bot[bot]]

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

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

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

[paultsimura]

Proposal

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

When searching by an actual emoji, the EmojiPicker doesn't suggest an emoji with an exact match.

What is the root cause of that problem?

In the EmojiPickerMenu, we do not support search by an actual emoji, only by matching the normalized text.

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

We should check if the searchTerm is an emoji. If yes – look for an emoji with the exact match of the emoji.code using EmojiUtils.findEmojiByCode instead of an emoji suggestion by text.

We can achieve this by making the following changes (or splitting the logic into separate assignments, but the general idea is the same):

const newFilteredEmojiList = EmojiUtils.containsOnlyEmojis(normalizedSearchTerm) 
            ? [EmojiUtils.findEmojiByCode(normalizedSearchTerm)].filter(Boolean) 
            : EmojiUtils.suggestEmojis(`:${normalizedSearchTerm}`, preferredLocale, emojis.current.length);

https://github.com/Expensify/App/blob/03a9fe09d8d736b5fc268e885a5f56b878846074/src/components/EmojiPicker/EmojiPickerMenu/index.js#L181

Result:

https://github.com/Expensify/App/assets/12595293/75ccd545-474d-4684-b7f3-f087187bd5da

What alternative solutions did you explore? (Optional)

If we want to support a non-strict search, but to search for multiple emojis at the same time, we can instead use the following:

   const newFilteredEmojiList = EmojiUtils.containsOnlyEmojis(normalizedSearchTerm)
            ? EmojiUtils.extractEmojis(normalizedSearchTerm)
            : EmojiUtils.suggestEmojis(`:${normalizedSearchTerm}`, preferredLocale, emojis.current.length);

[ta106]

Proposal

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

When we search using an emoji we don't realize that it is the one that should be selected.

What is the root cause of that problem?

In the EmojiPickerMenu.native.js

const filterEmojis = _.debounce((searchTerm) => {
        const normalizedSearchTerm = searchTerm.toLowerCase().trim().replaceAll(':', '');

        if (emojiList.current) {
            emojiList.current.scrollToOffset({offset: 0, animated: false});
        }

        if (normalizedSearchTerm === '') {
            setFilteredEmojis(allEmojis);
            setHeaderIndices(headerRowIndices);

            return;
        }
        const newFilteredEmojiList = EmojiUtils.suggestEmojis(`:${normalizedSearchTerm}`, preferredLocale, allEmojis.length);
        setFilteredEmojis(newFilteredEmojiList);
        setHeaderIndices(undefined);
    }, 300);

we don't catch if an emoji is selected

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

We should check if the searchTerm is an emoji, we should make it the selected emoji to be pushed We can do this by calling onEmojiSelected if the search is an emoji

const emojiCode = EmojiUtils.findEmojiByCode(normalizedSearchTerm);
if (emojiCode) {
     onEmojiSelected(emojiCode.code, emojiCode);
     return;
}

What alternative solutions did you explore? (Optional)

Maybe we do something like discord where we disable the native emoji suggestions

[yh-0218]

Proposal

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

When we search using an emoji we don't realize that it is the one that should be selected.

What is the root cause of that problem?

Because we didn't handle emoji search when input emoji. https://github.com/Expensify/App/blob/0cca90ab9aa7fd9467ef45ca35c4d0ad3c3334ae/src/components/EmojiPicker/EmojiPickerMenu/index.native.js#L84 and https://github.com/Expensify/App/blob/0cca90ab9aa7fd9467ef45ca35c4d0ad3c3334ae/src/components/EmojiPicker/EmojiPickerMenu/index.js#L181

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

We need to handle like this.

const convertedSearchTerm  = EmojiUtils.findEmojiByCode(normalizedSearchTerm)
        ? EmojiUtils.getEmojiName(EmojiUtils.findEmojiByCode(normalizedSearchTerm))
        :normalizedSearchTerm

const newFilteredEmojiList = EmojiUtils.suggestEmojis(`:${convertedSearchTerm}`, preferredLocale, emojis.current.length);

What alternative solutions did you explore? (Optional)

https://github.com/Expensify/App/assets/65789015/813be777-08ed-4b5e-b4e1-59742e8643a2

[yh-0218]

This is a Emojis suggesting Modal.

[twisterdotcom]

Man this is super niche. @burczu any of these proposals good? Going to downgrade to Weekly though.

[DylanDylann]

Proposal

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

• Emojis - "No results found" message appears when select "Hand" from keyboard suggestion

  What is the root cause of that problem?

• In the EmojiPickerMenu, we do not support search if the emoji code is typed.

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

• In other application, like slack, skype, if we type the emoji code to the search input, it will convert to emoji name. For example, if we type the thumb-up emoji :+1:, it will display as :+1:.

• We can do the same in our app, by updating: https://github.com/Expensify/App/blob/8b5306468bc9660124bad97df6142f19354649f0/src/components/EmojiPicker/EmojiPickerMenu/index.js#L167 to:

• const [searchTermValue, setSearchTermValue] = useState('');

const filterEmojis = _.throttle((searchTerm) => {

• let originalSearchTerm = searchTerm;
• if (EmojiUtils.containsOnlyEmojis(originalSearchTerm)) {
• const emojiName = EmojiUtils.findEmojiByCode(originalSearchTerm)?.name;
• if (emojiName) {
• originalSearchTerm = originalSearchTerm.replaceAll(originalSearchTerm, :${emojiName}:);
• }
• }
• const normalizedSearchTerm = originalSearchTerm.toLowerCase().trim().replaceAll(':', '');
• setSearchTermValue(originalSearchTerm);

...

}, throttleTime);

- Also, we need to handle the case users typing more than one emoji. The general idea is when user type "✋😀abc", it will create an array  ['✋', '😀', 'a', 'b', 'c'] and check if the element is emoji or not. If true, replace it with an emoji name (Ex: ✋ => ```:hand:```). Finally, join the result array  ```[':hand:', ':grinning:', 'a', 'b', 'c']``` to a string. For example, the above code change can become:
````diff
+    const [searchTermValue, setSearchTermValue] = useState('');
const filterEmojis = _.throttle((searchTerm) => {
+  let originalSearchTerm = searchTerm;
+        let originalSearchTermCharacters = [...originalSearchTerm];
+        originalSearchTermCharacters.forEach((character, index) => {
+            if (EmojiUtils.containsOnlyEmojis(character)) {
+                const emojiName = EmojiUtils.findEmojiByCode(character)?.name;
+                if (emojiName) {
+                    originalSearchTermCharacters[index] = `:${emojiName}:`;
+                }
+            }
+        });
+        originalSearchTerm = originalSearchTermCharacters.join('');
+        const normalizedSearchTerm = originalSearchTerm.toLowerCase().trim().replaceAll(':', '');
+        setSearchTermValue(originalSearchTerm);

• The above is just a quick code change to demo the idea, the detail should be handled in PR

What alternative solutions did you explore? (Optional)

Result

Screencast from 24-11-2023 00:55:29.webm

[twisterdotcom]

Not overdue, also not daily.

[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? 💸

[burczu]

@twisterdotcom I like the most the proposal from @paultsimura but I agree it's very niche and I'm not sure if we should fix this. I've checked on Slack and it works the same as in Expensify App - please see the video below:

https://github.com/Expensify/App/assets/7771498/2056ab00-5f87-42df-92cc-3975ecb20964

[DylanDylann]

@burczu

• In slack, if we copy the emoji from native app, it will be (Example if we type the thumb-up emoji 👍, it will display as :+1:):

Screencast from 04-12-2023 18:20:37.webm

• It is also mentioned in my proposal

[burczu]

@DylanDylann So we should not change how we search for emojis, but how we copy/paste them, right? Right now, if you copy emoji and paste it to the search input, it shows up as emoji, but it should appear as the code - it should work as expected then.

[DylanDylann]

@burczu

So we should not change how we search for emojis, but how we copy/paste them, right

• Yeah. I agree with it

Right now, if you copy emoji and paste it to the search input, it shows up as emoji, but it should appear as the code - it should work as expected then.

• There are two cases we need to consider:
  1. Copy the emoji from another app, in slack, 👍 is still 👍 (same as Expensive)
  2. Copy the emoji from native app, in slack, 👍 will display as :+1: (in Expensive, 👍 is still 👍)

[burczu]

Yes, but I still don't think it's worth fixing - on native devices users will use emoji pickers embedded in the screen keyboard, not our custom emoji picker; on desktop they will use keyboard to search for emoji because if they can copy emoji from somewhere else, why would they search it in the emoji picker if they can just paste it in the editor input?

[DylanDylann]

@burczu Yeah. It's just my opinion.

if they can copy emoji from somewhere else, why would they search it in the emoji picker if they can just paste it in the editor input?

• In slack, if we paste the emoji to the search input and then remove any characters, we can search the related emojis. Just for reference

Screencast from 04-12-2023 18:46:03.webm

[twisterdotcom]

Look, I think the benefit of having a great open source codebase is that we can fix anything, no matter how small. There's no time restriction on this one, but if we have a fix that can make our cross platform app work consistently, I think it's fine for us to "fix" it.

[paultsimura]

If this is worth fixing, I don't see any benefit in complicating things with the way we copy-paste the emojis in the emoji search bar instead of using the direct emoji matching. From my user experience, it did happen sometimes that I was trying to look for an emoji in the emoji picker, entered the (half-)name, and tapped the autocompletion – when the emoji is inserted into the picker search bar, I would expect an easy way to "transfer" it from the emoji picker into the composer – and in this case, the 1:1 match is the way to go IMHO.

[situchan]

I remember this was closed as not bug. Finding GH

[situchan]

Dupe of https://github.com/Expensify/App/issues/24399

[paultsimura]

Dupe of #24399

With all due respect, this issue is different as it has nothing to do with the copy-paste behavior of the emojis within the app – it's only related to the EmojiPicker's search logic.

[melvin-bot[bot]]

@burczu @twisterdotcom this issue was created 2 weeks ago. Are we close to approving a proposal? If not, what's blocking us from getting this issue assigned? Don't hesitate to create a thread in #expensify-open-source to align faster in real time. Thanks!

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

@burczu, @twisterdotcom Eep! 4 days overdue now. Issues have feelings too...

[burczu]

@DylanDylann I like what we discussed above - is it reflected in your proposal already?

[DylanDylann]

@burczu

I like what we discussed above

Which discussion are you mentioning?

[burczu]

@DylanDylann Like, here and here

[twisterdotcom]

Hmm https://github.com/Expensify/App/issues/24399 does have some interesting discussion about the complexity of the fix vs the likelihood for real users encountering this.

Things are moving fast here at Expensify HQ and we are moving towards a world where only real world reported bugs will be fixed, so I'm here to retract my previous viewpoint and say that I think given this is so unlikely to affect a real world user, we should close and perhaps when we come back to fixing every little thing, we'll do this then.

@burczu and @DylanDylann and everybody else, I definitely appreciate the discussion on this.