Repository navigation
Fix-up message decoration when mentioned in an edited messages with MSC3952 #24923
Description
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_contentinstead 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
contentwithcontent["m.new_content"]and then run push rules over that to see if there are any highlights).
- Implementation-wise, I'm not really sure how to do this, one option could be to "clone" the event, but replace the
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.
- 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.
This should apply to both pre-MSC3952 and MSC3952 mentions
Activity
daniellekirkwood commentedon Mar 27, 2023
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 commentedon Mar 27, 2023
@t3chguy did you mention that we were starting to incorp different designs for messages with keywords/replies/mentions?
t3chguy commentedon Mar 27, 2023
@daniellekirkwood element-hq/element-meta#744
clokep commentedon Mar 27, 2023
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 commentedon Mar 27, 2023
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 commentedon Mar 27, 2023
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:
clokep commentedon Mar 27, 2023
Not quite, it should be:
This matches the behavior pre-MSC3952, which is broken by MSC3952's implementation.
kerryarchibald commentedon Mar 30, 2023
Updated the ticket description to include the expected behaviour resolved in Patrick's comment.
Merge tag 'v1.11.30' into sc
Merge tag 'v1.11.30' into sc