Reply fallbacks are incorrectly rendered if they are missing the relationship metadata

[ara4n]

Very long-term bug (since Nov 2018 or so) - if a client sends a reply without a...

    "m.relates_to": {
      "m.in_reply_to": {
        "event_id": "$another:event.com"
      }
    }

...block on the event, iOS will misrender the fallback badly - suffixing the response to the blockquote, and then cropping off the bottom of the reply.

For instance:

  {
    "decrypted": {
      "type": "m.room.message",
      "sender": "@erikj:jki.re",
      "content": {
        "body": "> <@matthew:matrix.org> erik: what is the longest path through a fanout path? (as it is longer than the longest network path, right?)\n\nHard to say really, each hop has to be strictly closer in cost than the last",
        "format": "org.matrix.custom.html",
        "formatted_body": "<mx-reply><blockquote><a href=\"https://matrix.to/#/!nOUsIUkdCEMFqwiMXO:matrix.org/$1542740858118861tLlIU:matrix.org\">In reply to</a> <a href=\"https://matrix.to/#/@matthew:matrix.org\">@matthew:matrix.org</a><br>erik: what is the longest path through a fanout path? (as it is longer than the longest network path, right?)</blockquote></mx-reply>Hard to say really, each hop has to be strictly closer in cost than the last",
        "msgtype": "m.text"
      },
      "event_id": "$1542743465654FTBHk:jki.re",
      "origin_server_ts": 1542743465442,
      "unsigned": {
        "age": 81449840146
      },
      "room_id": "!nOUsIUkdCEMFqwiMXO:matrix.org"
    },
    "encrypted": {
      "content": {
        "algorithm": "m.megolm.v1.aes-sha2",
        "ciphertext": "AwgAEqAGBoicJDF7UKYlBGi/Sj4YcWTBbtV7C8/s1gsxdiQri0Bwsh/d84jUgXEMBBxVQ3vUHOh5B5zACPEG2EP9q/6lJLme4zghUDIlp//JsvLgVhwk25BBNdnDGOkIr+RUnk6p4IVVN/UctAZ2OStk45CuBjwdnDlZKXdpUvtCvMlTJhC/XXWLP8ADWZVTHOLMsg3G44ZGy5NSgv2sTfbk650MefeY6mCZFlmNQNYgnMk4qzBfFe6jF9IS2PLtDOuyj5LU48OTeH2Ak0mXLXIEEHdq2s9C8xPLhm5napvq4KBWz5Rdc+XcFgWxjSTrdHpggb1hdcRLlc2Jqfc6m4LBIWBKMQAIWOFnEaWxC3TXBTUICiVF95ar34d5ozv3FCuclrKVEgIUmllxuFTyY3Ic2teU5LQlPZ+sbZ/mg57dGvhFwq8YOQB21BWH1Gf/Mx0x7/iCQ9L9bIq8HCST+vD1MKj/+GluzqfSWDI5HuiO7HbCPIXAX23EEd73ocl7zno9aiULeTAfUwVcsx5dihyvs1urtE8x3miB/8PbLSvTOnNKN0VwWnW6Ht7LlLTRen8gsVLWgmioL+Ux1M44Pmf1qLWn4pM9NrAH3yVwWhTyq3aTAiKOpT5rPA+uSOuGvu5miEUaQw7zi2g9HjCoUxaHLIpxe9NNstPAgTq2dsGu4VYSSDxqsqeBAI2/ySQRKdhth/rwn8aXkmnz87nPZjOu5pdDXtEpXmb1r7c/pY4dlYFJgEPLYVpCgYjh3gwio9dl+JkZF9f7bFMYA1uKwwCKvVrTcSmPlDpiIg2V7PgvS2zrA89WHDEahD97NGMIAQdWjhC2l7EerGFbO9PkaPy3La2NcJ2qbA14/n00+1rvtYxKIBO6fUzo6+VaIbBwaszNLqg8/pACf4xjmPrRkjGU7X9Gr1FRz62KOmD/6hxxcL+GZ3obtxi2g+8wjm45oFbmU8PNTgV5teTEOaOD3hYRqoSvmkdR/T/6pczo63PvITy5bDSK8RBSjthO6/Q9T3p0rj8f2uPJuFPEcLWiHBYVYJ2s7ujCFROcPPaRyg90dY/aHDK/BZkax+Quou8bozlKNTVK7oqAnrjZYPykuJe/yu3BMvLJAKgxHu9LWMz9h10aMO+O4fh4LxtoY+anWlAjhKwiW4pYijX5mws",
        "device_id": "FKZUQGIXHG",
        "sender_key": "rFqH2z6JAgN9K+lSzf5cgwSwXaKDsKVnibQRzwxMN0c",
        "session_id": "wG1Y5b/0eYrTTm8to3ohoMAubvCw4XdV9cjPqFXIk3s"
      },
      "event_id": "$1542743465654FTBHk:jki.re",
      "origin_server_ts": 1542743465442,
      "room_id": "!nOUsIUkdCEMFqwiMXO:matrix.org",
      "sender": "@erikj:jki.re",
      "type": "m.room.encrypted",
      "unsigned": {
        "age": 81449840146
      },
      "user_id": "@erikj:jki.re",
      "age": 81449840146
    }
  },

is rendered as:

(ignore that the screenshot shows me replying rather than Erik; i had to forward it to take a screenshot, because reasons).

Eleweb renders it correctly (modulo missing some vertical whitespace after the blockquote) as:

It should be rendered by iOS to look like this:

I think there are other situations which trigger this failure mode, but the TL;DR is that iOS shouldn't misdisplay an event because of a minor problem on the sending client like this. I continue to see this failure mode fairly frequently.

[ara4n]

Confirmed fixed: