signalapp / Signal-Desktop

A private messenger for Windows, macOS, and Linux.
https://signal.org/download
GNU Affero General Public License v3.0
14.6k stars 2.66k forks source link

Emoji prediction does not follow spelling precisely #4235

Open geofurb opened 4 years ago

geofurb commented 4 years ago

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

scottnonnenberg-signal commented 4 years ago

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 commented 4 years ago

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 commented 3 years ago

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 commented 3 years ago

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

hiqua commented 3 years ago

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

scottnonnenberg-signal commented 3 years ago

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

ohare93 commented 3 years ago

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

hiqua commented 3 years ago

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