Message previews use mxid instead of display name when mentioning users

[HarHarLinks]

Description

Mentioning a user usually inserts a "pill" which Element resolves to a user's display name. This isn't done for the message preview and thus inconsistent and confusing.

Logs being sent: no

Version information

• Platform: desktop
• OS: Arch Linux
• Version: Element Nightly version: 2021012201 (https://aur.archlinux.org/packages/element-desktop-nightly-bin/)

Kind of related maybe: element-hq/element-meta#1603

[t3chguy]

Cannot reproduce

[HarHarLinks]

Event source:

{
  "content": {
    "body": "@s3858136:tu-dresden.de could it be your inbound federation is broken?",
    "format": "org.matrix.custom.html",
    "formatted_body": "<a href=\"https://matrix.to/#/@s3858136:tu-dresden.de\">@s3858136:tu-dresden.de</a> could it be your inbound federation is broken?",
    "msgtype": "m.text"
  },
  "origin_server_ts": 1611486186934,
  "room_id": "!xYvNcQPhnkrdUmYczI:matrix.org",
  "sender": "@sorunome:sorunome.de",
  "type": "m.room.message",
  "unsigned": {
    "age": 945599308
  },
  "event_id": "$KzOkHACRdW-gMFTb8uaX6SRlFwx5ZDhwUL1dsh-zjRE",
  "user_id": "@sorunome:sorunome.de",
  "age": 945599308
}

https://matrix.to/#/!xYvNcQPhnkrdUmYczI:matrix.org/$KzOkHACRdW-gMFTb8uaX6SRlFwx5ZDhwUL1dsh-zjRE?via=bpulse.org&via=matrix.org&via=maunium.net

sorunome is probably using another client than element to send this message. this issue might stem from the fact that pills are not specced (to my knowledge?).

however if element resolves <a href=\"https://matrix.to/#/@s3858136:tu-dresden.de\">@s3858136:tu-dresden.de</a> to display the current name in the timeline, it should do so consistently for the preview as well.

[t3chguy]

The issue is their Pills don't contain the Display Name in the fallback as they ought to:

<a href=\"https://matrix.to/#/@s3858136:tu-dresden.de\">@s3858136:tu-dresden.de</a>

Resolving pills in message previews across the entire breadth of rooms a user is in could end up being quite computationally expensive as they can yield network requests per-pill

[HarHarLinks]

If this is specced ("When mentioning users, use the user's potentially ambiguous display name for the anchor's text. If the user does not have a display name, use the user's ID."), then the root of this issue lies at another client, but there is still room for element to be nice and try to improve the situation.

Edit: imo, element is to blame partially for this issue by resolving the name at one place, but not the other.

How about updating the preview after the message window resolved the display name and notices it is different from the given fallback? Next to no additional cost and increases consistency ("UX").

[t3chguy]

No additional computational cost, but a lot of software complexity around plumbing that together in React.

Given that it doesn't show bolds, strikethroughs, etc, it is already chosen to be inconsistent.