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

Custom msgtypes appear as "Unsupported event" #1539

Closed
ghost opened this issue Oct 11, 2023 · 3 comments · Fixed by #1549
Closed

Custom msgtypes appear as "Unsupported event" #1539

ghost opened this issue Oct 11, 2023 · 3 comments · Fixed by #1549
Assignees
Labels
A-Timeline O-Occasional Affects or can be seen by some users regularly or most users rarely S-Major Severely degrades major functionality or product features, with no satisfactory workaround T-Enhancement New features, changes in functionality, performance boosts, user-facing improvements X-Needs-Rust This issue needs a Rust SDK change. It must have a link to a Rust SDK issue

Comments

@ghost
Copy link

ghost commented Oct 11, 2023

Your use case

What would you like to do?

When I execute the /fireworks woo hoo! command fireworks are displayed on Element for PC.
However, on Element X the message cannot be read at all, instead it displays "Unsupported event".
The same happens with other message types that have additional visual effects, namely /snowfall, /confetti or /rainfall.

Why would you like to do it?

At least see the message contents

How would you like to achieve it?

Idk

Have you considered any alternatives?

You can hold down the message and click "View Source" and then read the message from JSON, but this is inconvenient.

Additional context

Normal text message:

{
  "type": "m.room.message"
  "content": {
    "msgtype": "m.text"
    "body": "test",
  },
  "room_id": "[REDACTED]",
}

Fireworks text message:

{
  "type": "m.room.message",
  "content": {
    "msgtype": "nic.custom.fireworks",
    "body": "woo hoo!",
    "m.mentions": {}
  }
}

Are you willing to provide a PR?

No

@ghost ghost added the T-Enhancement New features, changes in functionality, performance boosts, user-facing improvements label Oct 11, 2023
@bmarty bmarty self-assigned this Oct 11, 2023
@bmarty
Copy link
Member

bmarty commented Oct 11, 2023

I agree that unknown msgtype should still display the body of the content in the timeline. This is what the spec is recommanding. I will see if I can do a quick fix for this.

@bmarty bmarty added S-Major Severely degrades major functionality or product features, with no satisfactory workaround O-Occasional Affects or can be seen by some users regularly or most users rarely labels Oct 11, 2023
@bmarty
Copy link
Member

bmarty commented Oct 11, 2023

OK, I think we will need a change in the Rust SDK (or in the uniffi layer). There is a mix which is not clear to me on the mapping there between Event type and msgtype in the event content, when "type" = "m.room.message".

Anyway, for m.room.message, even if msgtype is not supported, the body field must be provided to the application for it to render the fallback properly.

@bmarty bmarty added the X-Needs-Rust This issue needs a Rust SDK change. It must have a link to a Rust SDK issue label Oct 11, 2023
bmarty added a commit that referenced this issue Oct 11, 2023
@bmarty
Copy link
Member

bmarty commented Oct 11, 2023

Actually I can fix for the room list and for the timeline, but not for the notification.

PR: #1549
Rust issue about adding notification support: matrix-org/matrix-rust-sdk#2703

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Timeline O-Occasional Affects or can be seen by some users regularly or most users rarely S-Major Severely degrades major functionality or product features, with no satisfactory workaround T-Enhancement New features, changes in functionality, performance boosts, user-facing improvements X-Needs-Rust This issue needs a Rust SDK change. It must have a link to a Rust SDK issue
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant