[MMS] A reply to a multi-recipient MMS is not grouped in the same thread

RESOLVED WONTFIX

Status

Firefox OS
RIL
RESOLVED WONTFIX
5 years ago
3 months ago

People

(Reporter: isabelrios, Unassigned)

Tracking

unspecified
x86_64
Windows 7
Dependency tree / graph

Firefox Tracking Flags

(blocking-b2g:-, b2g-v1.4 affected, b2g-v2.0 affected, b2g-v2.1 affected)

Details

(Whiteboard: MMS_TEF, groupmms, permafail, )

Attachments

(2 attachments)

(Reporter)

Description

5 years ago
Created attachment 759120 [details]
Two threads created

Bug seen on Unagi v1-train
Gecko-65bbcee
Gaia-13c6246

PROCEDURE
1. DuT A: Send MMS to  multi recipients with international format: B(+34xxxxxxxxx) and C(+34yyyyyyyyy)
2. B replies to the group MMS
3. Verify whether the reply is correctly manage in the thread

EXPECTED
DuT A shows only one thread with the original MMS and the different replies from B and/or C inside it.

ACTUAL
DuT A shows two different threads, the original group MMS and a new on with B international format number

Comment 1

5 years ago
Impossible to do - SMS replies are sent individually to each recipient which is why they are in their own thread.  If you reply with an MMS it shows up correctly in the thread.

If we were to force group messages to be sent as MMS this works, but we aren't doing this.

needinfo? on ayman to verify
Flags: needinfo?(aymanmaat)
(Reporter)

Comment 2

5 years ago
Hi Corey,

The reply was also an MMS, please see attached file. There you could see the original MMS and the reply, also an MMS.

Thanks

Comment 3

5 years ago
(In reply to Isabel Rios [:isabel_rios] from comment #2)
> Hi Corey,
> 
> The reply was also an MMS, please see attached file. There you could see the
> original MMS and the reply, also an MMS.
> 
> Thanks

I was about to point that out as well and ask Isabel if that was indeed the case. But she has just confirmed it.

needinfo me again if you require my input corey
Flags: needinfo?(aymanmaat)
Blocking for now, MMS work.
blocking-b2g: leo? → leo+
I was looking at this bug and bug 880251 too because I have the feeling that they may be caused by the same root issue, namely that the MMS threadId field is not set correctly.

However since I'm having a bit of trouble reproducing it on my device mostly because I haven't yet got MMS functionality to work correctly (carrier configuration instructions are... confusing) I was wondering if you could post the communication app indexedDB database and attach it to this bug. This way I should be able to reproduce the problem simply by loading the DB with the test messages on my phone.

To pull the DB first enable remote debugging via the settings app then look for a file called ***communications.gaiamobile.org under the /data/local/indexedDB folder using adb; on my phone it looks like this:

$ adb shell ls /data/local/indexedDB | grep communications.gaiamobile.org
6+f+app+++communications.gaiamobile.org

Once you have the correct filename pull it via adb:

$ adb pull /data/local/indexedDB/6+f+app+++communications.gaiamobile.org 6+f+app+++communications.gaiamobile.org

This should yield a folder with all the relevant data in it; zip it and attach it to the bug.
Flags: needinfo?(isabelrios)
Corey and I discussed this last week and determined that somehow the threadId needs to be sent along with the outgoing message, in a way that it will be preserved/returned in any corresponding incoming messages.
(Reporter)

Comment 7

5 years ago
Hi Gabriele,

Sorry for the late reply. Attached you can find the files you asked for. Hope that helps.
Flags: needinfo?(isabelrios)
(Reporter)

Comment 8

5 years ago
Created attachment 762663 [details]
comms files

Comment 9

5 years ago
This issue tested on Leo 1.1 (Test Run Firefox OS 1.1.0 Full – Leo)
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/8e3f39363c54
Gaia: ea18de80fd04110756becaed214656642388401d
Platform Version: 18.0

STEPS
1. From the DUT send an MMS to multiple recipients
2. Receive an answer from one of the recipients
3. Check where this answer is stored and shown

EXPECTED
DuT shows only one thread with the original MMS and the answer should be shown on the original MMS thread.

ACTUAL
DuT shows two different threads, the original group MMS sent and a new one with the answer received

Link to failed test case:
https://moztrap.mozilla.org/manage/case/7974/
Whiteboard: MMS_TEF → MMS_TEF, leorun3
I'd say that we should be able to map an array of recipients to a thread id. The array of recipients should be matched whatever the order is.

This is a Gecko problem, I'll try to investigate and see if I can come up with a patch.
Assignee: nobody → felash
Component: Gaia::SMS → DOM: Device Interfaces
Product: Boot2Gecko → Core
of course this is what's already done. I've switched DEBUG mode in dom/mobilemessage/src/ril/MobileMessageDatabaseService.js.
It seems that all these bugs are related... Wait until next week for fixing them with Taipei Team!.
Whiteboard: MMS_TEF, leorun3 → MMS_TEF, leorun3, TaipeiWW
Assignee: felash → nobody

Updated

5 years ago
Whiteboard: MMS_TEF, leorun3, TaipeiWW → MMS_TEF, leorun3, TaipeiWW, groupmms

Updated

5 years ago
Target Milestone: --- → 1.1 QE3 (26jun)
Triage Comment : Passing on to David to help check the status and have the right assignee here.
Assignee: nobody → david.scravaglieri
As decided in Taipei, we won't probably keep any of the "groupmms" bugs in leo.
leo? given comment 14
blocking-b2g: leo+ → leo?
Assignee: david.scravaglieri → nobody
blocking-b2g: leo? → koi?
Per triage decision, all groupmms moving to koi? as the feature is no longer in leo.

Updated

5 years ago
Whiteboard: MMS_TEF, leorun3, TaipeiWW, groupmms → MMS_TEF, leorun3, groupmms
This also occurs when sending a group SMS on buri v1.2. The sent group messages are split up into different threads instead of being in one thread.

Environmental Variables
Build ID: 20130916040205
Gecko: http://hg.mozilla.org/mozilla-central/rev/c4bcef90cef9
Gaia: a0079597d510ce8ea0b9cbb02c506030510b9eeb
Platform Version: 26.0a1
Whiteboard: MMS_TEF, leorun3, groupmms → MMS_TEF, leorun3, groupmms, burirun1
Please disregard comment 17. After further research it was determined that the SMS is a separate issue and should be logged accordingly.
Whiteboard: MMS_TEF, leorun3, groupmms, burirun1 → MMS_TEF, leorun3, groupmms
Whiteboard: MMS_TEF, leorun3, groupmms → MMS_TEF, leorun3, groupmms, burirun1
All groupmms moving to comms backlog, Bug 891754
Blocks: 891754
blocking-b2g: koi? → ---
Whiteboard: MMS_TEF, leorun3, groupmms, burirun1 → MMS_TEF, leorun3, groupmms, burirun1, burirun2
ckreinbring> this feature was removed from v1.2.

Updated

5 years ago
Whiteboard: MMS_TEF, leorun3, groupmms, burirun1, burirun2 → MMS_TEF, leorun3, groupmms, burirun1, burirun2, burirun3

Updated

5 years ago
Whiteboard: MMS_TEF, leorun3, groupmms, burirun1, burirun2, burirun3 → MMS_TEF, groupmms, permafail
Component: DOM: Device Interfaces → RIL
Product: Core → Firefox OS
Target Milestone: 1.1 QE3 (26jun) → ---
Whiteboard: MMS_TEF, groupmms, permafail → MMS_TEF, groupmms, permafail, burirun1.3-3
Whiteboard: MMS_TEF, groupmms, permafail, burirun1.3-3 → MMS_TEF, groupmms, permafail,
status-b2g-v1.4: --- → affected

Updated

4 years ago
blocking-b2g: --- → backlog
status-b2g-v2.0: --- → affected
QA Whiteboard: [QAnalyst-Triage?]
status-b2g-v2.1: --- → affected
Flags: needinfo?(dharris)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(dharris)

Updated

4 years ago
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
blocking-b2g: backlog → -
Julien - I noticed that if I am involved in a multi-user message with two android phones which one android phone initiates, they will not be grouped in the same thread. They will be in two different threads. I believe the message should be using MMS as it's multi-user.

I am just wondering if that is due to this bug, or if I should file a new bug?
Flags: needinfo?(felash)
Yeah, this is this bug (or at least closely related).

As you might see we stopped working on groupmms and put it in a "sort of working" state, with clear issues as the one you see.

The main technical issue is bug 880251 -- we'd need to find out how other platforms are dealing with this.
Flags: needinfo?(felash)
Blocks: 1106663

Comment 23

3 months ago
Firefox OS is not being worked on
Status: NEW → RESOLVED
Last Resolved: 3 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.