Closed Bug 880598 Opened 11 years ago Closed 7 years ago
[MMS] When replying to a multi-recipient MMS, the number of contacts in header is increased
Bug seen on Unagi v1-train Gecko-65bbcee Gaia-13c6246 PROCEDURE At least devices A and B are unagi devices with v1-train. 1. From device A send an MMS to device B and C. 2. From device B answer to A with an MMS 3. Check the numbers of recipients shown in the header in device B after pressing Send. EXPECTED The number of recipients shown in header does not change ACTUAL The number of group participants is increased in one. Adding dep to bug 880251
I'm not sure where we ended up with group messaging. Requesting ni? from Ayman to determine whether this a bug or expected.
(In reply to Dietrich Ayala (:dietrich) from comment #1) > I'm not sure where we ended up with group messaging. Requesting ni? from > Ayman to determine whether this a bug or expected. This is a bug. It is not be possible to add or remove recipients from a group MMS message thread once the initial message has been sent. Therefore the number of recipients observable in the header of the thread on all devices who register the group message (sender and receiver devices) is fixed after the initial message is sent or received. In view of this the number of recipients in the header of a give group MMS message thread on any of the devices should not increase or decrease if recipients reply to the MMS.
dietrich, based on ayman's input we allread read it as a bug, hence leo + on this. Can you please help find an assignee or cc the right folks ?
blocking-b2g: leo? → leo+
I think Rick could be the best candidate for this issue, but I could take that if he has no free cycle for that. I think something need to be confirmed before kick off: In comment #0 case, should we display all the participants on header instead of sender A only in step 2?
Steve, I can look at this now (taking)
Assignee: nobody → waldron.rick
I'm still having service issues (not related to Gaia, Gecko, RIL or B2G)
Some thoughts... The participants count is derived from the message object's participant array length (-1 to account for the participant name we're currently displaying, ie. Jane (+1) means there are 2 participants). If the count is changing after the fact, then I'm concerned that the message object itself is causing the issue—which means it's coming from navigator.mozMobileMessage
Rick I've seen that this bug is unassigned, but probably is a bugzilla error when sending your new comment. Are u gonna work on this? Thanks!
This is definitely a bug. Here we are going to remove the workaround in Gaia for retrieving the length of participants once this param will be working properly in Gecko (bug 880251). Taking this due to I was doing the workaround and this is a followup. Thanks!
I think it's not just a gecko issue and gaia might need lots of extra work to handle the group mms message properly...(some details already described in bug 880251 comment 12) Hi Ayman, I create a video for this issue : https://docs.google.com/file/d/0B7CDMebivgCGM0pjS0daTTIwSWc/edit?usp=sharing . You can see the FxOS device received a group message with sender's number only in the header, but the header will turn into "sender(+2)" when you reply with a mms message. Currently only sender will receive the replied mms message. Should we reply the mms message as the group message, or normal single message in this case? Both solutions will need some efforts in gaia: 1) Reply the mms message as the group message to all the participants: Seems we need to display participants in the header instead of sender only when message received. Showing the our device number in the participants is reasonable for me, but the problem is we could not exclude the our number in participants list while replying message. 2) Reply the mms message to sender only: Should we show other participants in the header in this case? User might think all the participants in the group will receive the reply(but it's not actually). My Android device will thread the group message into sender's number, but it will display a group message icon in the message bubble and user can see the complete participant list by long press on the message, and only sender will receive the reply message in this case.
+1 to Steve. This is both Gaia & Gecko, and I think next week will be the best for fixing this due to we are going to work together during the WW :).
Whiteboard: MMS_TEF, TaipeiWW → MMS_TEF, TaipeiWW, groupmms
Target Milestone: --- → 1.1 QE3 (26jun)
please set back to leo? if groupmms is no longer targeted for 1.1
Target Milestone: 1.1 QE3 (26jun) → ---
Per triage decision, all groupmms moving to koi? as the feature is no longer in leo.
blocking-b2g: leo+ → koi?
removing my needinfo request. We will discuss again when the time comes
Whiteboard: MMS_TEF, TaipeiWW, groupmms → MMS_TEF, groupmms
blocking-b2g: koi? → ---
QAWANTED as we're not sure whether it still reproduces now.
We can't really test because receiving group MMS is currently disabled (it means we receive them as if it's not a group MMS).
Mass closing of Gaia::SMS bugs. End of an era :(
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
Mass closing of Gaia::SMS bugs. End of an era :(
You need to log in before you can comment on or make changes to this bug.