neilalexander / seaglass

A truly native Matrix client for macOS - written in Swift/Cocoa, with E2E encryption support
Other
529 stars 34 forks source link

Reply fallbacks are displayed mangled #51

Open ara4n opened 6 years ago

ara4n commented 6 years ago

A typical reply looks like:

 "content": {
    "body": "> <@travis:t2l.io> Speaking of energetic people: This is a thing: https://github.com/vector-im/riot-web/issues/7225\n\nI mean, an off switch seems reasonable",
    "format": "org.matrix.custom.html",
    "msgtype": "m.text",
    "formatted_body": "<mx-reply><blockquote><a href=\"https://matrix.to/#/!WCHwNGGsrVwPeRtAnq:matrix.org/$15351393601534DPmHV:t2l.io\">In reply to</a> <a href=\"https://matrix.to/#/@travis:t2l.io\">@travis:t2l.io</a><br>Speaking of energetic people: This is a thing: https://github.com/vector-im/riot-web/issues/7225</blockquote></mx-reply>I mean, an off switch seems reasonable",
    "m.relates_to": {
      "m.in_reply_to": {
        "event_id": "$15351393601534DPmHV:t2l.io"
      }
    }
  },

The formatted_body uses the cheeky <mx-reply/> custom tag to point out where the reply text is (so a client which understands it can hide it or handle it specially). Otherwise the plain text & HTML representation both include a fallback of the message contents which should show a usable version of the reply.

The fallbacks are getting mangled by Seaglass however - presumably it's trying to parse the plaintext body as MD and getting it quite badly wrong. Riot shows the message based on the HTML-with-knowledge-of-the-mx-reply-tag as:

screen shot 2018-08-25 at 02 39 30

but Seaglass shows it as:

screen shot 2018-08-25 at 02 44 22

(also, where's half-shot's avatar gone? :)

ara4n commented 6 years ago

(obviously, in an ideal world, you'd be parsing both the m.in_reply_to field to do proper semantic replies, as well as parsing the <mx-reply> block in the HTML in order to nicely display the reply portion and clip it from subsequent replies.)

neilalexander commented 6 years ago

The display of this might have been fixed by 5896ec4 as there was a conflict of constraints between the image placeholder and the text placeholder which was causing multi-line messages to not expand properly.

However, there's no parsing specifically of m.in_reply_to yet so yes, that will require a closer look so that it looks more elegant. Right now it just looks as good as the Markdown can produce, which isn't very good at all.