Signal-desktop: Emoji prediction does not follow spelling precisely

[geofurb]

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

Platform Info

Signal Version:

v1.33.4

Operating System:

Windows 10 (10.0.18363)

Linked Device Version:

4.58.5

[scottnonnenberg-signal]

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.

[geofurb]

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.

[hiqua]

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.

[scottnonnenberg-signal]

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