Incorrect behavior of message resend dialog

[shaaati]

Scenario: I am member of a group and a message did not get through (e.g., because I have a bad network connection). I then am presented with a message stating that I should tap for further details.
After tapping I see a message detail dialog together with a list of all group members and separate "send again" buttons for every member.

Problem: Whenever I tap on one of those buttons the message is not only resent to this specific member but to the whole group. To get rid of all buttons I would need to tap them all, thereby causing the message to be sent multiple times to every person.
I see that there might be cases in which some members have got the message while others have not. In that case it would be good if the button would only cause a resend to this specific account.
Often, it will be the case that none of the members got the message because the network issue is on the sender side. In that case, a "send again to whole group" button would be preferable.

[real-or-random]

I'd like to notice that this is one of the most annoying bugs at the moment. It often happens and my friends keep complaining about it every time, so it creates quite some dissatisfaction. I guess it's not different for other groups.

[ghost]

The whole group chat is broken on so many levels. People uninstalling/reinstalling is handled so badly. I don't use group chats in textsecure because it was only wasting our time :( That's the main usability problem that textsecure has at the moment.

[aurisnoctis]

👍 for this issue

[lazlolazlolazlo]

This is a really annoying bug, and happening a lot.

[BT80]

Does the textsecure architecture allow resending a group message to specific group members (in this case to those who failed to receive the message)?

[haffenloher]

I played around with the Android Studio debugger for the first time today and tried to find the cause of this issue.

I found that MessageRecipientListItem.java#L185 never gets executed because for group messages, record.recipients only contains a Recipient with name and number being the string "Unknown".

I finally came up with this change to MmsDatabase.java#L722:

Index: src/org/thoughtcrime/securesms/database/MmsDatabase.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
--- src/org/thoughtcrime/securesms/database/MmsDatabase.java    (date 1433332323000)
+++ src/org/thoughtcrime/securesms/database/MmsDatabase.java    (revision )
@@ -719,7 +719,7 @@
     contentValues.put(THREAD_ID, threadId);
     contentValues.put(READ, 1);
     contentValues.put(DATE_RECEIVED, contentValues.getAsLong(DATE_SENT));
-    contentValues.remove(ADDRESS);
+    contentValues.put(ADDRESS, message.getRecipients().getPrimaryRecipient().getNumber());

     long messageId = insertMediaMessage(masterSecret, sendRequest.getPduHeaders(),
                                         sendRequest.getBody(), contentValues);

(adapted from SmsDatabase.java#L434)

Now, record.recipients in MessageRecipientListItem.java#L185 contains a Recipient with name = "Some Group Name" and number = "__textsecure_group__!some_group_id" and the resend button only resends to the selected recipient.
However, as I don't know my way around the code base yet, I have no idea if this is a reasonable solution without side effects. Maybe someone more experienced could chime in.

[real-or-random]

I have no experience with the code base but his sounds like a good first step that at least removes the buggy behaviour (though it does not improve the UI). I'd recommend opening a pull request to get more feedback.

[Strubbl]

👍 for this issue - especially in context of duplicate issue #3339

[fungs]

Will this be fixed in the release branch soon? This really is the show stopper for private groups, as people tend to not use or uninstall the app if they get annoyed.

[fungs]

Can we expect a fix in the release branch any time soon?

[agrajaghh]

@fungs don't bump issues, its not helping at all...

https://github.com/WhisperSystems/Signal-Android/wiki/Welcome-to-the-Signal-Community#issue-guidelines

[2-4601]

And if you want to help with this issue the best way is to test #3383.

[nicdumz]

As an aside, is the UX any different in desktop / iOS world?

Perhaps (naively) stating the obvious: it seems that any UX change in the Android world would need to be backported to those versions, too. I'm not sure that #3383 takes care of this at all.

Cheers!

[peterpanondrugs]

Still occurs the problem. it happens quite often and its super annoying.
ios log https://gist.github.com/6d881bed7d6fb54faecbdef7c1a913fb
android log https://gist.github.com/ea564ca69aa6e504036ffdc405a8c538

[fpetry]

What about the according PR #3383?
Messages in big groups are received multiple times if there was bad reception. I have seen users leave Signal because of this strange behaviour ("It's better in other messengers...). If the fix is there, why isn't it merged to the version used by end users?

[sedrubal]

Sorry for asking but aren't there message IDs? Then it was easy to not display messages with the same ID more than once on receiver side...

[Trolldemorted]

No, there are not.

Receivers are ignoring messages with the same ciphertext according to liliakai, but libsignal-service-java does not allow resending with the same ciphertext.

If you get moxie to promise to have a look at a PR that fixes that, i will gladly (try to) fix it, but the amount of ignored PRs for libsignal-service-java is very discouraging.

[0o-o0]

Definitely still seeing the problem on my Pixel. When I have bad service and a message doesn't send I get the red "resend" buttons. It will resend the message as many times as I tap the button, but button doesn't disappear or indicate in any way that the message was successfully sent and received. Definitely the most significant pain-point experienced by my contacts (and for me as well because I need to just tap it once and hope that they got the message so as not to irk them).

[automated-signal]

GitHub Issue Cleanup:
See #7598 for more information.