This was initially reported as a feature request, but according to other community members, this is functionality which does not work as intended.
The original discussion topic can be found here: https://community.signalusers.org/t/always-show-read-indicator-on-last-read-message/10107
Currently, if I send two messages and my contact reads the first one but closes Signal before my second message arrives, I will see on my screen two message bubbles with only a delivery indicator on the second message bubble. Only if I check te details on the first message can I tell that this message has in fact also been read.
This is a bit misleading, I might assume my contact hasn鈥檛 read any of the messages I have send, because unless I check for it, I wouldn鈥檛 see a read indicator anywhere.
Keep in mind, both sides have their read indicators enabled and thus opted that they want to see this information.
Actual result: Both messages have been send in short sequence to each other. only the bottom message shows indicators, and it shows the delivered indicator not the read indicator
Expected result: The first message has a different read status, and should show its read indicator despite these messages being send in short sequence to each other, so I can see that this earlier message has in fact been read (or at least been displayed to my contact).
Device: Motorola Moto G7 Plus
Android version: 9.0
Signal version: 4.50.1
Design error, log not relevant.
Note that the in the discussion on the community forums, another issue was discussed where status is shown on messages where this is not necessary. https://community.signalusers.org/t/always-show-read-indicator-on-last-read-message/10107/7?u=meteor0id
This may be addressed as well.
So this is, in fact, intended. The reason has to do with reducing "collapse jitter" as messages are sent.
To start, pending messages are always uncollapsed. However, we otherwise don't prevent collapse based on different delivery/read statuses. Imagine the following scenario where we do prevent collapse based on different delivery statuses:
So from the user's perspective, they sent a message, and then a moment later, a bunch of stuff collapsed down. It looks jittery, and we didn't want it. I used delivery receipts in this example, but same applies to read receipts.
There are perhaps more complex things we could do like not collapsing things until you leave the thread and come back, but that gets super tricky/ugly to implement, and we decided to keep it simple. Either way, feel free to continue discussion on the forum.
Most helpful comment
So this is, in fact, intended. The reason has to do with reducing "collapse jitter" as messages are sent.
To start, pending messages are always uncollapsed. However, we otherwise don't prevent collapse based on different delivery/read statuses. Imagine the following scenario where we do prevent collapse based on different delivery statuses:
So from the user's perspective, they sent a message, and then a moment later, a bunch of stuff collapsed down. It looks jittery, and we didn't want it. I used delivery receipts in this example, but same applies to read receipts.
There are perhaps more complex things we could do like not collapsing things until you leave the thread and come back, but that gets super tricky/ugly to implement, and we decided to keep it simple. Either way, feel free to continue discussion on the forum.