Signal-desktop: 'Unread messages' header sticks around even if mobile device sent message in that convo

Created on 15 Nov 2017  路  4Comments  路  Source: signalapp/Signal-Desktop

  • [x] I have searched open and closed issues for duplicates

Bug description

When in conversation, if I send a gif from the Android client, the desktop client adds my message to the unread count section instead of marking it as read. Not sure if this is the Android side not sending the right info or the desktop not processing something correctly so I started here.

Steps to reproduce

  • in 1x1 conversation, have one unread message from the other person
  • send gif from android client

Actual result: my message increases unread count instead of noting it marked read
Expected result: my own message coming in would update to marking things read

Screenshots

image

Platform info

Operating System: Win 7
Signal version: 1.0.38

Debug log

INFO  2017-11-15T16:38:27.774Z GET https://cdn.signal.org/profiles/bCKX64toYsTIaUGC9SvrCg
INFO  2017-11-15T16:38:28.315Z GET https://cdn.signal.org/profiles/bCKX64toYsTIaUGC9SvrCg 200 Success
INFO  2017-11-15T16:38:33.846Z Sending a keepalive message
INFO  2017-11-15T16:39:28.949Z Sending a keepalive message
INFO  2017-11-15T16:39:47.017Z queueing envelope +[REDACTED]776.1 1510763986077
INFO  2017-11-15T16:39:47.018Z message from +[REDACTED]776.1 1510763986077
INFO  2017-11-15T16:39:47.018Z New remote ephemeral key
INFO  2017-11-15T16:39:47.075Z Deleting chain closed at 1510593875224
INFO  2017-11-15T16:39:47.086Z read receipt +[REDACTED]776 1510763847477
INFO  2017-11-15T16:39:47.086Z read receipt +[REDACTED]776 1510763857855
INFO  2017-11-15T16:40:10.836Z queueing envelope +[REDACTED]776.1 1510764009869
INFO  2017-11-15T16:40:10.837Z message from +[REDACTED]776.1 1510764009869
INFO  2017-11-15T16:40:10.863Z data message from +[REDACTED]776.1 1510764009869
INFO  2017-11-15T16:40:10.933Z adding notification
INFO  2017-11-15T16:40:10.933Z updating notifications - count: 1 focused: false enabled: true
INFO  2017-11-15T16:40:10.933Z draw attention
INFO  2017-11-15T16:40:10.935Z remove all notifications
INFO  2017-11-15T16:40:13.309Z Sending 1 read receipts
INFO  2017-11-15T16:40:13.311Z Sending 1 read receipts
INFO  2017-11-15T16:40:13.365Z PUT https://textsecure-service.whispersystems.org/v1/messages/+[REDACTED]936
INFO  2017-11-15T16:40:13.379Z PUT https://textsecure-service.whispersystems.org/v1/messages/+[REDACTED]776
INFO  2017-11-15T16:40:13.884Z PUT https://textsecure-service.whispersystems.org/v1/messages/+[REDACTED]936 200 Success
INFO  2017-11-15T16:40:13.920Z PUT https://textsecure-service.whispersystems.org/v1/messages/+[REDACTED]936
INFO  2017-11-15T16:40:14.351Z PUT https://textsecure-service.whispersystems.org/v1/messages/+[REDACTED]936 200 Success
INFO  2017-11-15T16:40:18.598Z PUT https://textsecure-service.whispersystems.org/v1/messages/+[REDACTED]776 200 Success
INFO  2017-11-15T16:40:18.653Z PUT https://textsecure-service.whispersystems.org/v1/messages/+[REDACTED]776
INFO  2017-11-15T16:40:19.046Z PUT https://textsecure-service.whispersystems.org/v1/messages/+[REDACTED]776 200 Success
INFO  2017-11-15T16:40:20.463Z queueing envelope +[REDACTED]776.1 1510764013311
INFO  2017-11-15T16:40:20.464Z delivery receipt from +[REDACTED]776.1 1510764013311
INFO  2017-11-15T16:40:20.485Z No message for delivery receipt +[REDACTED]776 1510764013311
INFO  2017-11-15T16:40:21.466Z queueing envelope +[REDACTED]776.1 1510764013313
INFO  2017-11-15T16:40:21.467Z delivery receipt from +[REDACTED]776.1 1510764013313
INFO  2017-11-15T16:40:21.482Z No message for delivery receipt +[REDACTED]776 1510764013313
INFO  2017-11-15T16:40:54.017Z queueing envelope +[REDACTED]936.1 1510764051437
INFO  2017-11-15T16:40:54.019Z message from +[REDACTED]936.1 1510764051437
INFO  2017-11-15T16:40:54.020Z New remote ephemeral key
INFO  2017-11-15T16:40:54.095Z sent message to +[REDACTED]776 1510764051437 from +[REDACTED]936.1 1510764051437
INFO  2017-11-15T16:40:54.095Z GET https://textsecure-service.whispersystems.org/v1/attachments/4523623330619035489
INFO  2017-11-15T16:40:54.505Z GET https://textsecure-service.whispersystems.org/v1/attachments/4523623330619035489 200 Success
INFO  2017-11-15T16:40:54.520Z GET https://whispersystems-textsecure-attachments.s3-accelerate.amazonaws.com/4523623330619035489?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Date=20171115T164054Z&X-Amz-SignedHeaders=content-type%3Bhost&X-Amz-Expires=3600&X-Amz-Credential=AKIAJHWS3AOTJTASHBDA%2F20171115%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Signature=6607bd03ecaf1a8ecda440006f2435d23f487f674ecf24f91d16de85f072f237
INFO  2017-11-15T16:40:55.169Z queueing envelope +[REDACTED]776.1 1510764051437
INFO  2017-11-15T16:40:57.462Z GET https://whispersystems-textsecure-attachments.s3-accelerate.amazonaws.com/4523623330619035489?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Date=20171115T164054Z&X-Amz-SignedHeaders=content-type%3Bhost&X-Amz-Expires=3600&X-Amz-Credential=AKIAJHWS3AOTJTASHBDA%2F20171115%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Signature=6607bd03ecaf1a8ecda440006f2435d23f487f674ecf24f91d16de85f072f237 200 Success
INFO  2017-11-15T16:40:57.547Z delivery receipt from +[REDACTED]776.1 1510764051437
Bug Chrome Standalone

Most helpful comment

I just checked the reverse of this scenario, and if Android finds out that Desktop sent a message in a conversation, it will get rid of the 'unread messages' header. So I think we can make the change to conform to that behavior.

All 4 comments

This is actually by design, though you're right, in this situation it's a little weird. That unread messages header only goes away when you send a message in that thread from that client, or leave the conversation and come back. So, if a new message comes in from yourself, should it increment, or should it no longer match the set of messages below it?

The idea is to use that header as a tool to point you at the stuff you maybe haven't seen yet.

In this scenario, I suppose we could drop the header entirely on desktop, since you've viewed the conversation on your other device... Thoughts?

This isn't too big of a deal so I don't want to belabor it much. I was thinking that if I sent a message on one client I should be able to assume I've read the prior ones, but maybe that assumption is not valid given the asynchronous nature of messaging. Maybe if read receipts are turned on, that would have enough information to mark things read if they are? Other than that, I don't have a better idea. It was just a little weird, but certainly not egregious.

I just checked the reverse of this scenario, and if Android finds out that Desktop sent a message in a conversation, it will get rid of the 'unread messages' header. So I think we can make the change to conform to that behavior.

This will go out in the next version of Signal Desktop (production).

Was this page helpful?
0 / 5 - 0 ratings