Closed Bug 952407 Opened 11 years ago Closed 9 years ago

[Buri][IOT]Limit of MMS is incorrect

Categories

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

defect

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 990481

People

(Reporter: sync-1, Assigned: steveck)

References

Details

Attachments

(4 files)

Mozilla build ID:20130916041201
 +++ This bug was initially created as a clone of Bug #574284 +++
 PROBLEM DESCRIPTION:
 The MMS maximum size is configured as 1 Mb but the customer needs the setting to be 300 Kb
 
 EXPECTED BEHAVIOUR:
 the maximum MMS should be 300KB
 We should have a variable in Clid to control the MMS size, in Android platform we have the variable def_mms_max_mms_size
 
 STEPS TO REPRODUCE:
 1. Go to menu "Messages" -> "New menssage" -> "Attachement"
 2. Select various files upper to 600 Kb.
 3. Notice that the DuT allows to attach more files after to it show the message that indicated "Ha alcanzado la longitud m
Hey, could you please be a little more precise?

On my phone, it's correctly set at 300Kb. What are you seeing?
Also, can you show messages in english?

Thanks
Flags: needinfo?(sync-1)
When the size of attachments is more than the limitation, we can still add more attachments in the mms. I think it's unreasonable.
Flags: needinfo?(sync-1)
Because the resize algorithm has different level, the pictures can be resized
to different results. Sometimes the prompt alert user it has reached its max
length unless some contents be removed. But with more pictures added, the
picture resizing level come to a lower one and its capacity dose not reach its maximum again. More ones could be added successfully.
Because the resize algorithm has different level, the pictures can be resized
to different results. Sometimes the prompt alert user it has reached its max
length unless some contents be removed. But with more pictures added, the
picture resizing level come to a lower one and its capacity dose not reach its maximum again. More ones could be added successfully.
Sorry tianm, I don't exactly understand what is the bug :)

Is it about adding images? videos?

Can you be more precise?

Thanks!
Dear  Julien Wajsberg
The resizing algorithm will not resize one pictures which is not bigger than 300.The resizing algorithm will resize every single picture to a limit of 120K if there are less than three pictures, else a limit of 60k.
What's more, only pictures can be resized, audios and videos can't be resized.

At first, we add some videos to mms, and then add pictures. When pictures are resizing as a limit of 120k, attachments have reached their max capacity and some prompt come out to alert user. Then the users think no more attachments can be added. However attachments still could be added, and when the pictures are more than 3 (or equal 3),  every single pictures will be added as a limit of 60k, the prompt will disappear and there are still some space left.

BRs,
TIAN Min
I think it's unreasonable, and this is the reason why file this bug.
Dear  Julien Wajsberg
The resizing algorithm will not resize one pictures which is not bigger than 300.The resizing algorithm will resize every single picture to a limit of 120K if there are less than three pictures, else a limit of 60k.
What's more, only pictures can be resized, audios and videos can't be resized.

At first, we add some videos to mms, and then add pictures. When pictures are resizing as a limit of 120k, attachments have reached their max capacity and some prompt come out to alert user. Then the users think no more attachments can be added. However attachments still could be added, and when the pictures are more than 3 (or equal 3),  every single pictures will be resized as a limit of 60k, the prompt will disappear and there are still some space left.

I think it's unreasonable, and this is the reason why file this bug.

BRs,
TIAN Min
Received more information from Vance Chen:

The IOT tester in the AT4 lab find this behavior a little bit confusing, because:

    Even after the oversize prompt appear, end users still can keep inserting the media objects into MMS
    With certain inserting sequence, the resize mechanism will be triggered and reduce the MMS size, suddenly user are allowed to insert the media objects again.
    The timing to trigger picture resizing is strange, only when there are more than 2 pictures in the MMS the resize mechanism will be triggered. So if we have a 160 kB video and 160 kB picture, the picture will not be resized despite the fact that the image is indeed resizable.

So maybe it is not a software defect per se, but the design and behavior is somehow confusing to end users. TCL already came out a patch(because they are in a hurry to pass the Chile/Peru IOT test). Please refer to the attached patch file as well to see if you have any comments
Attached video example video
Hey Steve,

Do you have the time to handle this bug and this patch, since you initially wrote this part of code?  Thanks!
Flags: needinfo?(schung)
(In reply to Julien Wajsberg [:julienw] (PTO until January 6th) from comment #13)
> Hey Steve,
> 
> Do you have the time to handle this bug and this patch, since you initially
> wrote this part of code?  Thanks!

Sure, but I might not take the same solution as TCL did. I will propose another method for video/photo mixed situation:

- If total size is not exceeded, we won't resize the image.
- If total size is exceeded, resize the image to 1/5 max mms limitation. If total video/audio attachment size already exceed 4/5 total limited size, we will not resize the image for remaining space.
Assignee: nobody → schung
Flags: needinfo?(schung)
Summary: [Buri][HOMO]Limit of MMS is incorrect → [Buri][IOT]Limit of MMS is incorrect
See Also: → 990481
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: