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

Status: RESOLVED FIXED

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

Description

[sync-1]

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.

Comment 1

[Julien Wajsberg [:julienw]]

any video, or more precise content?

Comment 2

[bhavana bajaj [:bajaj]]

A video will be very helpful, I was also curious what you meant by "newspapers MMS" in your STR ?

Comment 3

[田旻]

(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.

Comment 4

[Preeti Raghunath(:Preeti)]

What is the length at which cut off happens?

Comment 5

[田旻]

Attachment: 724537861.mp4

There are too videos for this bug, this is the 1st one.

Comment 6

[田旻]

Attachment: 734494756.mp4

There are two videos for this bug, this is the 2nd one.

Comment 7

[Julien Wajsberg [:julienw]]

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 ?

Comment 8

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

(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)

Comment 9

[Julien Wajsberg [:julienw]]

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.

Comment 10

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

Attachment: 螢幕快照 2014-03-04 下午5.15.29.png

Comment 11

[Julien Wajsberg [:julienw]]

Vance, I mean, in the original MMS, not in the composer :)

Comment 12

[Julien Wajsberg [:julienw]]

I mean: where in the original MMS is located the text you're showing in attachment 8385184 [details]?

Comment 13

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

(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!

Comment 14

[Julien Wajsberg [:julienw]]

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?

Comment 15

[Noemí Freire (:noemi)]

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

Comment 16

[Preeti Raghunath(:Preeti)]

Moving to backlog. We believe this is per design.

Comment 17

[田旻]

(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.

Comment 18

[Steve Chung [:steveck]]

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!

Comment 19

[田旻]

Attachment: forward.log

I will give you database later, Vali coworker give me adb log and qxdm log this afternoon. This is the adb log.

Comment 20

[田旻]

Attachment: forward.rar

This is the qxdm log.

Comment 21

[田旻]

Attachment: DEVICE_DB.rar

This is database you need.

Comment 22

[Julien Wajsberg [:julienw]]

(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!

Comment 23

[Julien Wajsberg [:julienw]]

(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.

Comment 24

[Steve Chung [:steveck]]

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?

Comment 25

[田旻]

(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.

Comment 26

[Steve Chung [:steveck]]

Sorry about the network issue... I can download the complete file now, thanks!

Comment 27

[Jason Smith [:jsmith]]

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.

Comment 28

[Julien Wajsberg [:julienw]]

(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.

Comment 29

[Steve Chung [:steveck]]

Attachment: 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.

Comment 30

[Julien Wajsberg [:julienw]]

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 :)

Comment 31

[Steve Chung [:steveck]]

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!

Comment 32

[Julien Wajsberg [:julienw]]

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

Comment 33

[Steve Chung [:steveck]]

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?

Comment 34

[Julien Wajsberg [:julienw]]

Yep, as I said, let's not spend more time than necessary here, the calling sequence will be good enough !

Thanks a lot Steve

Comment 35

[Julien Wajsberg [:julienw]]

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 :(

Comment 36

[Steve Chung [:steveck]]

(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

Comment 37

[Steve Chung [:steveck]]

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

Comment 38

[Ryan VanderMeulen [:RyanVM]]

v1.3: a51c46d5e39679c1aafe7f1dbb715c993030d68e