Special characters are escaped in headings when they shouldn't be
Steps to reproduce
- Have a chat open
- Have the other party send one of the following messages if they're on Element, if not on Element then a message that produces the same source:
#
{
"type": "m.room.message",
"content": {
"org.matrix.msc1767.message": [
{
"body": "# <(^-^<)",
"mimetype": "text/plain"
},
{
"body": "<h1><(^-^<)</h1>\n",
"mimetype": "text/html"
}
],
"body": "# <(^-^<)",
"msgtype": "m.text",
"format": "org.matrix.custom.html",
"formatted_body": "<h1><(^-^<)</h1>\n"
}
}
/html <h1><;(^-^<;)</h1>
{
"type": "m.room.message",
"content": {
"org.matrix.msc1767.message": [
{
"body": "<h1><(^-^<)</h1>",
"mimetype": "text/plain"
},
{
"body": "<h1><(^-^<)</h1>",
"mimetype": "text/html"
}
],
"body": "<h1><(^-^<)</h1>",
"msgtype": "m.text",
"format": "org.matrix.custom.html",
"formatted_body": "<h1><(^-^<)</h1>"
}
}
Outcome
What did you expect?
Android devices should unescape special characters first before rendering the heading. For example, on Element Desktop and on GitHub it'll look like this:
<(^-^<)
What happened instead?
The less-than (<) symbols aren't unescaped, so the < from when the content was converted to HTML is used literally and the user actually sees this:
<(^-^<)
A screenshot from the Android device:

Your phone model
Fairphone 4
Operating system version
Android
Application version and app store
No response
Homeserver
one.ems.host
Will you send logs?
No
Are you willing to provide a PR?
Yes
I am not sure what you mean with "headings" but it happens in normal messages too.
Just send some text from Element Android with an ampersand in it. It will appear as & when rendered in the timeline.
I don't use Android, so I only know about the issue that was screenshotted and shared with me. Headings refers to using Markdown to create a heading.
# This is a Heading!
This is a Heading!
Yeah, this happens in half my messages, too:

Duplicate of #6445
Hmm, I'll make my wife check for updates and check this out again. If the bug is resolved, I'll close the issue.
thanks for raising! this is indeed #6445 and was fixed as part of 1.4.28