Fix-up message decoration when mentioned in an edited messages with MSC3952

[clokep]

As part of #24377 initial support for MSC3952 was implemented in #9983. That implementation has a couple of bugs/deficiencies to fix-up around editing messages. (The below all assume you have MSC3952 support enabled.)

---

Currently if you're mentioned in a message it is displayed as red, if that message is then edited (e.g. fix a typo) it is no longer red. The implementation runs push rules over the event and if any event is a highlight than it gets displayed in red. See UnwrappedEventTile.shouldHighlight. This logic needs to be updated somehow for intentional mentions:

• @daniellekirkwood suggested that if the message or any version of it every notified the user (via a highlight) than the event should be red. (See conversation around here.)
• Another option (which the MSC suggests) is that the latest edit-only should be checked for mentions. This would be done by checking the mentions property of m.new_content instead of the root-level.
  • Implementation-wise, I'm not really sure how to do this, one option could be to "clone" the event, but replace the content with content["m.new_content"] and then run push rules over that to see if there are any highlights).

While doing this we should be sure to consider both user mentions & room mentions and that the push rules can be disabled by the user.

Similarly to the red text, we sure ensure the state of your own pill (if one exists) is consistent with whether the message itself is treated as a highlight or not.

---

Expected behaviour:

1. Someone mentioned me in a message.
2. They then edit the content (not the mentions)
3. My mention is still red

This matches the behavior pre-MSC3952, which is broken by MSC3952's implementation.
This should apply to both pre-MSC3952 and MSC3952 mentions

[daniellekirkwood]

It's disorienting for users to have a red notification on a room and then to see nothing in the timeline calling their attention... This would happen if the user was mentioned, and then the mention was removed from the timeline message via Edit. In this case, I think the message should stay Red (as it does today)

This is how the message looks when you are mentioned.

This is the suggestion for what the message looks like when the mention is removed but you were originally tagged in it.

We discussed that the all-red messages might be going away soon?
If this is the case, then the "(edit)" should be red, similar to how a keyword would be highlighted in this case.

Created new issue: #24970

[daniellekirkwood]

@t3chguy did you mention that we were starting to incorp different designs for messages with keywords/replies/mentions?

[t3chguy]

@daniellekirkwood element-hq/element-meta#744

[clokep]

In this case, I think the message should stay Red (as it does today)

It does not stay red today. If you remove a (pre-MSC3952) mention then it reverts back to normal text.

---

This bug (to be consistent with today's behavior) is that if you edit a message but leave the mention in, then it loses the red text when using MSC3952.

[clokep]

@daniellekirkwood element-hq/element-meta#744

Although we might want to update how this is displayed, I think this is a separate task from updating the logic to ensure it is displayed at the correct time. If it makes sense to do them at the same time, that's great, but I would hate to see the fixes here get stuck behind a design review when they don't really need it.

[daniellekirkwood]

Ahhh... Ok, then yes, let's move my comment to an Enhancement issue and leave this one as the bug...

So the definition of done here is:

• Someone mentioned me in a message
• They then edit the content (not the mentions)
• My mention is no longer red

[clokep]

So the definition of done here is:

• Someone mentioned me in a message
• They then edit the content (not the mentions)
• My mention is no longer red

Not quite, it should be:

• Someone mentioned me in a message.
• They then edit the content (not the mentions)
• My mention is still red

This matches the behavior pre-MSC3952, which is broken by MSC3952's implementation.

[kerryarchibald]

Updated the ticket description to include the expected behaviour resolved in Patrick's comment.