Closed Bug 976999 Opened 7 years ago Closed 7 years ago

[Sora][Message][MMS]Some of the text content lost when forward the MMS.

Categories

(Firefox OS Graveyard :: Gaia::SMS, defect, P1)

defect

Tracking

(blocking-b2g:1.3+, b2g-v1.3 fixed, b2g-v1.3T fixed, b2g-v1.4 fixed)

RESOLVED FIXED
1.4 S3 (14mar)
blocking-b2g 1.3+
Tracking Status
b2g-v1.3 --- fixed
b2g-v1.3T --- fixed
b2g-v1.4 --- fixed

People

(Reporter: sync-1, Assigned: steveck)

References

()

Details

(Keywords: regression)

Attachments

(7 files)

Firefox OS v1.3
 Mozilla build ID: 20140208004002 
 
 DEFECT DESCRIPTION:
 ->The text content lost.
 
  REPRODUCING PROCEDURES:
 ->MS received a newspapers MMS;
 ->View the MMS,long tap it select"Forward";
 ->You can find some of the text content lost.(ko)
 
 note:Build 20140118004001 is ok.
  
  EXPECTED BEHAVIOUR:
 ->Should be completely.
 
  ASSOCIATE SPECIFICATION:
 
  TEST PLAN REFERENCE:
 
  TOOLS AND PLATFORMS USED:
 
  USER IMPACT:
 
  REPRODUCING RATE:100%
 
  For FT PR, Please list reference mobile's behavior:Beetle lite FF don't have forward function.
blocking-b2g: --- → 1.3?
any video, or more precise content?
A video will be very helpful, I was also curious what you meant by "newspapers MMS" in your STR ?
Flags: needinfo?(sync-1)
(In reply to bhavana bajaj [:bajaj] from comment #2)
> A video will be very helpful, I was also curious what you meant by
> "newspapers MMS" in your STR ?

I will upload it as soon as possible.
What is the length at which cut off happens?
Attached video 724537861.mp4
There are too videos for this bug, this is the 1st one.
Attached video 734494756.mp4
There are two videos for this bug, this is the 2nd one.
So, I can definitely see that there is the last image attachment. But it's not clear to me what happens with the text.

Can you complete the STR to show in video what's missing ?
(In reply to Julien Wajsberg [:julienw] from comment #7)
> So, I can definitely see that there is the last image attachment. But it's
> not clear to me what happens with the text.
> 
> Can you complete the STR to show in video what's missing ?

OK after checking the videos and listening to the comments for several times, I think i can have a STR for this issue:

1. Receive a very long MMS from the carrier service.
2. As in the video 734494756(attachment #2 [details] [diff] [review]), this long mms contains lots of text and some pictures. Please pay attention to the picture appear at 00:12, you can see that above that picture there are quite a few characters.
3. Now long press to launch the menu to forward the MMS
4. Add one recipient and send out the MMS
5. Check the MMS you just sent out, you can see the text content is gone(As in the video 724537861, the picture again appear around 00:14, but the text above that picture are all gone)
Flags: needinfo?(sync-1)
Vance, I'll need a little more your help, because for me it's difficult to distinguish Chinese characters especially in a low quality video :(

In the second Video, we can see text above the picture, do you know where it was in the original MMS?

I wonder if we fail when we have 2 consecutive text attachments, as this is something we never generate, maybe we didn't correctly test this.
Flags: needinfo?(vchen)
Vance, I mean, in the original MMS, not in the composer :)
I mean: where in the original MMS is located the text you're showing in attachment 8385184 [details]?
(In reply to Julien Wajsberg [:julienw] from comment #9)
> Vance, I'll need a little more your help, because for me it's difficult to
> distinguish Chinese characters especially in a low quality video :(
> 
> In the second Video, we can see text above the picture, do you know where it
> was in the original MMS?
> 
> I wonder if we fail when we have 2 consecutive text attachments, as this is
> something we never generate, maybe we didn't correctly test this.

OK I just attached a screenshots of the video 2, as you can see, above the picture there are some chinese characters surround by [], they looks like:

[上海新聞]
[國際新聞]
[體育新聞]
[社會新聞]

----------------------------
 Picture is here           |
----------------------------

However, in the original message, it looks like:

[上海新聞]

LOTS OF CHINESE CHARACTERS

[國際新聞]


LOTS OF CHINESE CHARACTERS

[體育新聞]

LOTS OF CHINESE CHARACTERS

[社會新聞]


LOTS OF CHINESE CHARACTERS
----------------------------
 Picture is here           |
----------------------------

So to me, the chinese characters in the [] are some kind of "topics"/"headlines"/"categories""subjects", not sure if in the MMS SMIL format we have this kind of tag, and the "LOTS OF THE CHINESE CHARACTERS" are just the content part of the MMS SMIL page.

So only the subject remains,  but the content is stripped out.

Hope this helps!
Thanks, I don't say it helps me a lot ;) but it may help Steve !

Steve, since you know Chinese ( ;) ) and you worked on the original SMIL and attachments implementation, does something here make sense to you?
Flags: needinfo?(schung)
Could it be related to the maximum MMS_SIZE (300KB by default) parameter in case of trying to send a message with video and/or audio bigger than it?. For images and text there is an automatic squeeze algorithm but don't think so in case of video/audio. There is a specific message shown when you try to pick up files bigger than MMS_SIZE from gallery/video/music activities but not sure what happens in case of forwarding.
Notice that this limit is applied when sending but not when receiving so it is possible to receive MMSs bigger than MMS_SIZE
Moving to backlog. We believe this is per design.
blocking-b2g: 1.3? → backlog
(In reply to Noemí Freire (:noemi) from comment #15)
> Could it be related to the maximum MMS_SIZE (300KB by default) parameter in
> case of trying to send a message with video and/or audio bigger than it?.
> For images and text there is an automatic squeeze algorithm but don't think
> so in case of video/audio. There is a specific message shown when you try to
> pick up files bigger than MMS_SIZE from gallery/video/music activities but
> not sure what happens in case of forwarding.
> Notice that this limit is applied when sending but not when receiving so it
> is possible to receive MMSs bigger than MMS_SIZE

I think this bug is leaded by some kind of composition when forward.
My guessing is the forwarding message might contains some chars that cause certain paragraph of text are missed from(1) message bubble content -> composer field, or (2) composer field -> message bubble content.

Hi 田旻, could you help verify the content in the composer field is correct before you click send button? If the text already missed before you send, that means the message might trigger some unexpected error while converting the mms content into the composer field, otherwise it could be some error inside the mms message creation. You could dump your database by:

adb pull /data/local/storage/persistent/ /THE_PATH_FOR_SAVING_DEVICE_DB

Please attach you database which contains the mms message and we can start the investigation, thanks!
Flags: needinfo?(schung) → needinfo?(tianm)
Attached file forward.log
I will give you database later, Vali coworker give me adb log and qxdm log this afternoon. This is the adb log.
Flags: needinfo?(tianm)
Attached file forward.rar
This is the qxdm log.
Attached file DEVICE_DB.rar
This is database you need.
(In reply to Noemí Freire (:noemi) from comment #15)
> Could it be related to the maximum MMS_SIZE (300KB by default) parameter in
> case of trying to send a message with video and/or audio bigger than it?.

Good idea, but I don't think we're doing this in the middle of a forward. Worth checking though.


> For images and text there is an automatic squeeze algorithm but don't think
> so in case of video/audio.

not for text either ;)



(In reply to Steve Chung [:steveck] from comment #18)
> My guessing is the forwarding message might contains some chars that cause
> certain paragraph of text are missed from(1) message bubble content ->
> composer field, or (2) composer field -> message bubble content.

Yep, (1) most certainly. In the videos we see that something is missing already in the composer.


Thanks for the DB, this is very useful!
(In reply to Preeti Raghunath(:Preeti) from comment #16)
> Moving to backlog. We believe this is per design.

Who believes this?

Let's keep 1.3? while we investigate about the bug and see if this can reproduce in other situations. Then depending on what we find we can move this out of 1.3 or not.
blocking-b2g: backlog → 1.3?
Comment on attachment 8385916 [details]
DEVICE_DB.rar

I could not find the "chrome" folder in the zip file, does this folder exist when you pull out from device?
Flags: needinfo?(tianm)
(In reply to Steve Chung [:steveck] from comment #24)
> Comment on attachment 8385916 [details]
> DEVICE_DB.rar
> 
> I could not find the "chrome" folder in the zip file, does this folder exist
> when you pull out from device?

I can see the chrome folder in the first of the queue. I download it just now for you doubt, but I can still see the chrome folder.
Flags: needinfo?(tianm)
Sorry about the network issue... I can download the complete file now, thanks!
Assignee: nobody → schung
On an original read, we thought this was an expected limitation by the MMS size limitation for sending of messages. However, after reading comment 0 again, it indicates this was working on 1/18/2014 originally, which makes this a regression. On that regard, this is indeed a blocker.
blocking-b2g: 1.3? → 1.3+
Keywords: regression
(In reply to Jason Smith [:jsmith] from comment #27)
> On an original read, we thought this was an expected limitation by the MMS
> size limitation for sending of messages. However, after reading comment 0
> again, it indicates this was working on 1/18/2014 originally, which makes
> this a regression. On that regard, this is indeed a blocker.

Note that in the past, you didn't block on regressions for features that have not shipped in a previous version. The "forward" feature is new in v1.3.

I mean, I think we should try to resolve this, especially if it can happen in other situations. Just want to find the consistency here.

Bug 939971 could have regressed this, but we need to find the root cause to be sure.
Attached file Link to github
I think it's no a regression, it's a bug while inserting the composer with mms which contains multiple slides and multiple paragraphs of text, and we haven't tested before. The composer append have 2 behaviors, and parsing a mms message should not apply 'insert element at caret position' because it will delete previous selected range, and mms might contains many paragraphs of text to be appended. And that's why the middle of the text content disappeared.
Attachment #8386736 - Flags: review?(felash)
Comment on attachment 8386736 [details] [review]
Link to github

Added comments

mostly good, but I'd like to know if we can have a unit test reproducing the bug exactly, instead of spying internal methods.

So I'm keeping my r until this :)
Attachment #8386736 - Flags: review?(felash)
Comment on attachment 8386736 [details] [review]
Link to github

Hi Julien, I update the patch again with your suggestion. I also make some changes for unit test but it might still has some limitation that can't 100% fit your request. I put more details on the github, thanks!
Attachment #8386736 - Flags: review?(felash)
Comment on attachment 8386736 [details] [review]
Link to github

r=me with the comments but don't hesitate to ask a new review if you'd like another look on the test
Attachment #8386736 - Flags: review?(felash) → review+
The activityElement is still non-configurable and can't be deleted(and it sounds not a good way to force activityElement to certain object we expected), so maybe I should removing the output result verification and simply check the calling sequence of text append and focus, wdyt?
Flags: needinfo?(felash)
Yep, as I said, let's not spend more time than necessary here, the calling sequence will be good enough !

Thanks a lot Steve
Flags: needinfo?(felash)
Steve, don't forget to ask an approval to :fabrice when you're ready. I don't want to do it here because I haven't tested it myself :(
(In reply to Julien Wajsberg [:julienw] from comment #35)
> Steve, don't forget to ask an approval to :fabrice when you're ready. I
> don't want to do it here because I haven't tested it myself :(

Thanks for the notification, in master:
01cfa2ee50039ce481f81c4ab758d6299b9c7198
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Comment on attachment 8386736 [details] [review]
Link to github

NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment] 
[Bug caused by] (feature/regressing bug #): Bug for 1.3 feature
[User impact] if declined: Some mms text content will be lost while forwarding the message
[Testing completed]: Yes with unit tests
[Risk to taking this patch] (and alternatives if risky): low
[String changes made]: N/A
Attachment #8386736 - Flags: approval-gaia-v1.3?(fabrice)
Attachment #8386736 - Flags: approval-gaia-v1.3?(fabrice) → approval-gaia-v1.3+
v1.3: a51c46d5e39679c1aafe7f1dbb715c993030d68e
Target Milestone: --- → 1.4 S3 (14mar)
Flags: in-moztrap?
Flags: in-moztrap? → in-moztrap+
You need to log in before you can comment on or make changes to this bug.