Signal-Desktop icon indicating copy to clipboard operation
Signal-Desktop copied to clipboard

Emoji prediction does not follow spelling precisely

Open geofurb opened this issue 5 years ago • 9 comments

Bug Description

Emoji prediction does not follow spelling precisely in the Signal for Desktop client. (Tested on Windows 10.)

Steps to Reproduce

  1. Type ":rolling" and leave the cursor at the end of the g
  2. Emoj predictions appear, starting with ":drooling_face:" (Which supplies 🤤)

Actual Result:

Emoji predictions begin with ":drooling_face:" (🤤)

Expected Result:

Emoji predictions should include only emoji with "rolling" in their text. (e.g. ":rolling_on_the_floor_laughing:" (🤣) and ":face_wtih_rolling_eyes:" (🙄).

Screenshots

image

Platform Info

Signal Version:

v1.33.4

Operating System:

Windows 10 (10.0.18363)

Linked Device Version:

4.58.5

geofurb avatar Apr 30 '20 19:04 geofurb

We use fuzzy search, which includes results which don't match exactly. It does look like it prefers shorter strings in our current usage, given your example.

Can you talk a little bit about why you'd like non-exact search results to be removed entirely? We do expect them to be useful when typing quickly, or when your text has basic typos, or even when you don't know the exact spelling.

scottnonnenberg-signal avatar Apr 30 '20 22:04 scottnonnenberg-signal

Non-exact search results often appear before the exact results, and results are not prioritized according to the user's frequency-of-use. This is a frustrating behavior, as some emoji cannot be reached without triggering fuzzy detection for several other results, and the user has no easy way to get to the desired emoji. This feature can make the interface quite cumbersome.

geofurb avatar May 04 '20 00:05 geofurb

It's fine to keep non-exact matches, but as previously mentioned, the better matches should appear first. In case the origin of the bug is still unknown, I checked the example on the library used, and the library sorts the matches correctly (meaning that :rolling... appears before :drooling...). So the bug does not come from library, but from Signal-Desktop use of the results from the library.

Steps to reproduce:

Using https://fusejs.io/demo.html with:

list.json

[
   {
    "emoji": "flag_ae",
  },
    {
    "emoji": "pirate",
  },
  {
    "emoji": "rolling_on_the_floor_laughing",
  },
    {
    "emoji": "drooling_face",
  },
      {
    "emoji": "face_with_rolling_eyes",
  },
        {
    "emoji": "sweat_smile",
  },
          {
    "emoji": "sweat",
  },
]

main.js

const options = {
  // isCaseSensitive: false,
   includeScore: true,
   shouldSort: true,
  // includeMatches: false,
  // findAllMatches: false,
  // minMatchCharLength: 1,
  // location: 0,
  // threshold: 0.6,
  // distance: 100,
  // useExtendedSearch: false,
  // ignoreLocation: false,
  // ignoreFieldNorm: false,
  keys: [
    "emoji"
  ]
};

const fuse = new Fuse(list, options);

// Change the pattern
const pattern = "rolling"

return fuse.search(pattern)

results:

[
  {
    "item": {
      "emoji": "rolling_on_the_floor_laughing"
    },
    "refIndex": 2,
    "score": 0.001
  },
  {
    "item": {
      "emoji": "face_with_rolling_eyes"
    },
    "refIndex": 4,
    "score": 0.1
  },
  {
    "item": {
      "emoji": "drooling_face"
    },
    "refIndex": 3,
    "score": 0.15285714285714286
  }
]

Lower score means better match, meaning that rolling_... should come first, as it does in the output of the library when using the shouldSort option.

hiqua avatar Dec 04 '20 14:12 hiqua

@hiqua Thanks for this analysis. It looks like fuse sorts in an unexpected order. You can expect change soon in how Desktop uses fuse search results.

scottnonnenberg-signal avatar Dec 04 '20 19:12 scottnonnenberg-signal

@scottnonnenberg-signal should we try to implement a fix? Or is it on your roadmap already?

hiqua avatar Apr 05 '21 18:04 hiqua

@hiqua You're welcome to play with the fuse settings, but with fuzzy search you may very well cause another odd search result, or make search harder to use.

scottnonnenberg-signal avatar Apr 05 '21 21:04 scottnonnenberg-signal

Seems like there's a further issue here. When typing an emoji and you have any capital letters, it will not autocomplete upon hitting enter. Literally nothing happens, the text stays the same.

image

ohare93 avatar Jul 02 '21 04:07 ohare93

That's another issue: https://github.com/signalapp/Signal-Desktop/issues/5018 For which there is already a PR: https://github.com/signalapp/Signal-Desktop/pull/5186

hiqua avatar Jul 02 '21 05:07 hiqua

Can you reproduce this with 7.43 or ulterior?

Chealer avatar Feb 25 '25 17:02 Chealer