"Reply" composition lost if switching rooms during message composition

[michaelkaye]

Repoducible on /develop :

• have two rooms
• "reply" to a message in room1, partially compose a reply
• switch to room2
• switch to room1

Looking at the message to be sent, it has lost the 'reply' popout box and if sent will not include the message being replied to, which can lead to some odd messages that assume context from the message being replied to.

The UI is consistent - if it doesn't show it'll send a reply it doesn't send the reply, but we should retain the message composition state in general.

[turt2live]

Related: #6006 (yes, closed, but it describes a failure that should be avoided when fixing the OP)

[lukebarnard1]

We currently store a single replyingToEvent in RoomViewStore. We should really store a map between rooms and the replyingToEvent.

[t3chguy]

unless we also want it persisted across restarts, like composer history is

[turt2live]

storing that between restarts doesn't seem worth the effort to me. Chances are people won't click Reply then F5

[t3chguy]

It'd be consistent though, if someone hits Reply, types a message and then F5/browser crashes/whatever their reply-text will still be there but the replying state&target will have gone

[t3chguy]

there was also another point brought up IRL, should it persist in up/down arrow history, so say I reply to someone, send it and hit UP arrow, should the reply state be brought back? Semantically this seems right though how useful would it be is arguable