Replies sometimes show `<mx-reply>` until restart

[Nothing4You]

Describe the bug

I've seen it a couple times already that replies to messages display <mx-reply> before and </mx-reply> after the quoted message. Restarting nheko fixes the issue and it shows like a regular reply with quoted message.

To Reproduce

No idea.

Nico mentioned it would be generated by Element mobile clients, but I couldn't reproduce this in an empty room with just myself, neither with sending a reply nor with sending a reply and editing it afterwards.

What happened?

No response

Expected behavior

No response

Screenshots

Version

0.11.3-8ca0f61c

Operating system

macOS

Installation method

macOS DMG file

Qt version

No response

C++ compiler

No response

Desktop Environment

No response

Did you use profiles?

• [ ] Profiles used?

Relevant log output

No response

Backtrace

No response

[geekosaur]

FWIW I have seen this, and it seems to specifically be caused by replies from ElementX.

[geekosaur]

This is an example of a reply that triggers it:

{
    "content": {
        "body": "> <@acidalia:matrix.org> this time it's your fault, you use a terribly old cabal format version (https://github.com/simonmichael/hledger/blob/master/hledger/hledger.cabal#L1) and not an SPDX identifier, which means that you're caught in the translation phase from \"old\" license identifiers to SPDX identifiers: https://hackage.haskell.org/package/Cabal-syntax-3.10.2.0/docs/src/Distribution.License.html#licenseToSPDX\n\nThank you very much ! I use an old cabal format to maximize installability but it sounds like time for an update. ",
        "format": "org.matrix.custom.html",
        "formatted_body": "<mx-reply><blockquote><a href=\"https://matrix.to/#/!hskonBonfjiIefqLUV:matrix.org/$v8fSVQhekVcGcR3ePCXI3n2QG2mEFbDCcbefAIkcifI\">In reply to</a> <a href=\"https://matrix.to/#/@acidalia:matrix.org\">@acidalia:matrix.org</a><br>this time it's your fault, you use a terribly old cabal format version (https://github.com/simonmichael/hledger/blob/master/hledger/hledger.cabal#L1) and not an SPDX identifier, which means that you're caught in the translation phase from &quot;old&quot; license identifiers to SPDX identifiers: https://hackage.haskell.org/package/Cabal-syntax-3.10.2.0/docs/src/Distribution.License.html#licenseToSPDX</blockquote></mx-reply>Thank you very much ! I use an old cabal format to maximize installability but it sounds like time for an update. ",
        "m.relates_to": {
            "event_id": "$xvbyi8Ube9qfQmauWefLI9hgNoqgi0uH16Il2mJomOI",
            "is_falling_back": true,
            "m.in_reply_to": {
                "event_id": "$v8fSVQhekVcGcR3ePCXI3n2QG2mEFbDCcbefAIkcifI"
            },
            "rel_type": "m.thread"
        },
        "msgtype": "m.text"
    },
    "event_id": "$T220RaC7L2kZia5D5JnOMxhnbMhva4J54L7KSNZ3ctk",
    "origin_server_ts": 1710944404769,
    "sender": "@simonmic:matrix.org",
    "type": "m.room.message",
    "unsigned": {
        "age": 1031
    }
}

Note the absence of a newline after the </mx-reply>. This in my experience consistently is part of the messages that don't properly show as replies.

(Sorry for the delay; it's taken that long for me to catch one since my earlier report.)

[deepbluev7]

That message above is a violation of the spec, it has an mx-reply tag in the formatted body even though it has a m.thread relation. Nheko renders the mx-reply for those, since such events should not be sent and otherwise the client authors would never fix those bugs. Element (especially on Android) is also known to send invalid events like that regularly, so this is not a bug in Nheko but in Element.

[stefanceriu]

I might be missing something here but isn't Element X doing the right thing according to https://spec.matrix.org/latest/client-server-api/#fallback-for-unthreaded-clients?

events sent by clients which understand threads SHOULD include rich reply metadata to attempt to form a reply chain representation of the conversation