Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Emoji reactions with identical visual results are not grouped due to unnecessary VS16s #27331

Closed
hcsch opened this issue Apr 14, 2024 · 2 comments
Labels

Comments

@hcsch
Copy link

hcsch commented Apr 14, 2024

Steps to reproduce

  1. Start in any matrix room with existing messages
  2. Click the react button on an existing message
  3. Select the thumbs-up button
  4. Observe a thumbs-up emoji reaction appearing
  5. Use a different client (not known to me) which generates fully-qualified emoji without unnecessary VS16s to add another thumbs-up to the same message
  6. Observe two separate thumbs-up reactions that don't get grouped

Outcome

What did you expect?

Both thumbs-up reactions get grouped together, if they represent the same grapheme (i.e. both have the same visual representation), i.e. if an emoji without a text-representation has a superfluous VS16, it is grouped with the same emoji without.

Element should perhaps not generate unnecessary variation selectors and should maybe normalise emoji to their minimal representation that is still fully-qualified for reactions. This should probably still account for explicitly text-mode emoji (unclear if unqualified, clear if followed by VS15/U+FE0E), if those are intended to be supported.

What happened instead?

The visually identical reactions were grouped/counted separately.

Element generated U+1F44D U+FE0F (left in the image), while another client generated U+1F44D (right in the image), which according to https://unicode.org/Public/emoji/latest/emoji-test.txt is already fully-qualified and hence needs no VS16 (U+FE0F) to my knowledge.

Screenshot of two reaction pills; on the left, the one from Element with a superfluous VS16, on the right the one from another client without a VS16

Operating system

NixOS 24.05 (nixos-unstable)

Application version

Element version: 1.11.63 Crypto version: Rust SDK 0.7.0 (b1918e9), Vodozemac 0.5.1

How did you install the app?

Via NixOS package management

Homeserver

matrix.org

Will you send logs?

No

@hcsch hcsch added the T-Defect label Apr 14, 2024
@hcsch
Copy link
Author

hcsch commented Apr 14, 2024

The Element Android Emoji picker seems to generate a thumbs-up without VS16

@hcsch hcsch changed the title Emoji picker generates thumbs-up emoji with unnecessary VS16 Emoji reactions with identical visual results are not grouped due to unnecessary VS16s Apr 14, 2024
@t3chguy
Copy link
Member

t3chguy commented Apr 15, 2024

This is as per the spec.

https://spec.matrix.org/v1.10/client-server-api/#mreaction

If this is an emoji, it should include the unicode emoji presentation selector (\uFE0F) for codepoints which allow it (see the emoji variation sequences list).

@t3chguy t3chguy closed this as not planned Won't fix, can't repro, duplicate, stale Apr 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants