Signal-android: Always show read indicator on last read message

Created on 15 Nov 2019  路  1Comment  路  Source: signalapp/Signal-Android


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

Bug description

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.

Steps to reproduce

  • with read receipts enabled for both you and your contact, make sure both you and your contact have opened a conversation on your screens
  • send your contact a message
  • after receiving this message your contact immediately leaves the conversation
  • send another message

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).

Screenshots

Device info


Device: Motorola Moto G7 Plus
Android version: 9.0
Signal version: 4.50.1

Link to debug log


Design error, log not relevant.

Closely related enhancement

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.

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:

  • I send a message A. It is delivered. It is the most recent message, and therefore is uncollapsed.
  • I send another message B. It is pending. Message A will stay uncollapsed because it is "delivered", not "pending".
  • However, almost immediately, message B is sent, and then delivered.
  • Now the status does match A, and A will collapse down.

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.

>All comments

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:

  • I send a message A. It is delivered. It is the most recent message, and therefore is uncollapsed.
  • I send another message B. It is pending. Message A will stay uncollapsed because it is "delivered", not "pending".
  • However, almost immediately, message B is sent, and then delivered.
  • Now the status does match A, and A will collapse down.

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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

nxfifteen picture nxfifteen  路  3Comments

wesinator picture wesinator  路  3Comments

j3fffff picture j3fffff  路  3Comments

vvug picture vvug  路  3Comments

FeuRenard picture FeuRenard  路  3Comments