/spoiler includes spoiler text in raw text

[spaetz]

Steps to reproduce

1. Send a message in element-web with a /spoiler This is my spoiler text
2. View with a plaintext client or inspect event source
3. Plain text contains spoiler text!

Note, this is different from #14447 (spoiler text appears in notifications) but seems to be partially mentioned in element-meta element-hq/element-meta#1634 which makes it abundandly clear that element-web is doing the wrong thing here. The spec says:

When sending a spoiler, clients SHOULD provide the fallback in the body as shown above (including the reason). The fallback SHOULD NOT include the text containing spoilers since body might show up in text-only clients or in notifications. To prevent spoilers showing up in such situations, clients are strongly encouraged to first upload the text containing spoilers to the media repository, then reference the mxc:// URI in a markdown-style link, as shown above.

The spec also has a proposal on how the raw text is supposed to look like.

Outcome

What did you expect?

{
"type": "m.room.message",
"content": {
"msgtype": "m.text",
"format": "org.matrix.custom.html",
"body": "[Spoiler](mxc://example.org/abc123)", # per example in the spec
"formatted_body": "<span data-mx-spoiler>This is my spoiler text</span>"
}
}

What happened instead?

{
"type": "m.room.message",
"content": {
"msgtype": "m.text",
"format": "org.matrix.custom.html",
"body": "This is my spoiler text",
"formatted_body": "<span data-mx-spoiler>This is my spoiler text</span>"
}
}

Application version

Element version: 1.11.67

Will you send logs?

No

[t3chguy]

How exactly is this different to element-hq/element-meta#1634

When a spoilered message is sent with the /spoiler command, the plain-text fallback in the body key contains the content of the spoiler verbatim, with no attempt at obfuscation.

[spaetz]

It is different as that one focuses on previews and notifications too, and it is a element-meta issue, not specific to any client. It is element-web misbehaving, so that is why we are here. Feel free to close as duplicate if the element-meta is specific enough, I have to admit that I am out of my depth how you organize "meta" vs "client-specific" issues.

[t3chguy]

It is different as that one focuses on previews and notifications too

Those are both driven by the body or "raw text" as you call it so I'm considering this a duplicate

I have to admit that I am out of my depth how you organize "meta" vs "client-specific" issues.

Its in meta because we need the product team to decide what to do and then consistently apply that to all Element clients.