897840 - [Messages] limit to 20 recipients when sending MMS.

Status: RESOLVED WONTFIX

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

Description

[Leo]

1. Title: The handset does not reach the maximum number of recipients.
2. Precondition: Set Language To Brazilian  Portuguese
3. Tester's Action:  1. Mensagens > Nova mensagem;
                     2. Try to fill the maximum number of recipients.
                     3. Check the behavior
4. Detailed Symptom (ENG.) : The handset does not reach the maximum number of recipients.
5. Expected:  The handset should reach the maximum number of recipients
6. Reproducibility: Y
1) Frequency Rate : 100%
7. Gaia Master/v1-train: Reproduced on v1-train
8. Gaia Revision:  bbad03e30527e1df8261a462e5cefbdc562f0819
9. Personal email id: [e-mail]

Comment 1

[Wayne Chang [:wchang]]

Currently there is no maximum number of recipient restriction for SMS/MMS. 

Please let us know if there is a concern with this and we can take this into consideration in v1.2.

Comment 2

[Wayne Chang [:wchang]]

(In reply to Wayne Chang [:wchang] from comment #1)
> Currently there is no maximum number of recipient restriction for SMS/MMS. 
> 
> Please let us know if there is a concern with this and we can take this into
> consideration in v1.2.

Adding to my first comment - 
There is no restriction imposed by Gaia at the moment but Gecko restricts the maximum recipient to 20 per OMA-MMS-CONF 10.2.5.

flagging ffos-product to confirm if the improvement for Gaia should be made accordingly for v1.2.

Comment 3

[Wilfred Mathanaraj [:WDM]]

Does make sense to have the same limit as in Gecko at Gaia level as well. 

I will discuss with comms team as to how involved the implementation is to put this limit into Gaia for v1.2

Comment 4

[Rick Waldron [:rwaldron]]

This limitation is trivial to add to the actual SMS/MMS app code. The existing message length warning banner can be re-used to alert the user.

Comment 5

[Joe Cheng [:jcheng] (please needinfo)]

add to backlog 891754
ni? ayman

Comment 6

[Julien Wajsberg [:julienw]]

Gene, is there a way to know from Gaia the max recipients count used in Gecko ?

Comment 7

[Gene Lian (I already quit Mozilla)]

(In reply to Julien Wajsberg [:julienw] from comment #6)
> Gene, is there a way to know from Gaia the max recipients count used in
> Gecko ?

Currently, MMS_MAX_TOTAL_RECIPIENTS = 20.

I think it's not worth exposing extra API/preference/setting to expose this value, because it's a *constant* defined in the MMS spec and is not variable. I think Gaia can directly assume a fixed number 20 to design the UI.

SMS doesn't have this issue for sure since we can only send SMS to single person in any way.

Comment 8

[Julien Wajsberg [:julienw]]

Please correct me if I'm wrong, but I think that currently, in Gecko, we just send 20 different MMS too, since we disabled group MMS. Is that right ?

Comment 9

[Gene Lian (I already quit Mozilla)]

(In reply to Julien Wajsberg [:julienw] from comment #8)
> Please correct me if I'm wrong, but I think that currently, in Gecko, we
> just send 20 different MMS too, since we disabled group MMS. Is that right ?

No, we only disable grouping for receiving MMS. ;)

Comment 10

[Julien Wajsberg [:julienw]]

Oki thanks.

Ayman, what should we do when we reach that limit ? Should we send several MMS, or should we prevent the user from adding more recipients ?

Comment 11

[ankit93040]

Julien 

What I feel as a user as the number of recipients crosses 20 then the send button should be disabled & a toast message should be displayed indicating that the user has crossed the 20 recipient limit. And once the recipient count comes down to 20 then the send button can be enabled.

I wanted to have a suggestion? please suggest.

These 20 recipient limit is for MMS or SMS or both??

Comment 12

[Gene Lian (I already quit Mozilla)]

20 recipient is a limitation for MMS only.

Comment 13

[Julien Wajsberg [:julienw]]

(In reply to ankit93040 from comment #11)
> Julien 
> 
> What I feel as a user as the number of recipients crosses 20 then the send
> button should be disabled & a toast message should be displayed indicating
> that the user has crossed the 20 recipient limit. And once the recipient
> count comes down to 20 then the send button can be enabled.
> 
> I wanted to have a suggestion? please suggest.

I'd be more on the "send several MMS" side, like we do for SMS :)

I also think that if we do this, this should be handled by Gecko (because otherwise there is an hidden limitation of the API). What do you think Gene?

Comment 14

[ankit93040]

Hey

I have been working for these issue.

I have even completed with these.

Tomorrow I ll upload the video for the same.

For me as soon as the number of recipient crosses 20 counter a toast message is displayed "user has crossed the limit of 20 max recipient" & the send button is disabled.

But these is applicable for both SMS & MMS.

I mean it doesn't take into consideration whether it is an SMS or a MMS.

Now after the input from :Julienw & :Gene I tried to restrict these to only MMS.

but I felt as if whether its possible or not?

because the enable & disable send button function doesn't take into consideration whether it is an SMS or an MMS.

Restricting these to only MMS will be an Gaia or a Gecko issue?

please suggest!

Comment 15

[ankit93040]

Attachment: VID_0005.3gp

The patch that I have done is this & also the video shows the same.

For me as soon as the number of recipient crosses 20 counter a toast message is displayed "user has crossed the limit of 20 max recipient" & the send button is disabled.

But these is applicable for both SMS & MMS.

I mean it doesn't take into consideration whether it is an SMS or a MMS.

Now after the input from :Julienw & :Gene I tried to restrict these to only MMS.

but I felt as if whether its possible or not?

because the enable & disable send button function doesn't take into consideration whether it is an SMS or an MMS.

Restricting these to only MMS will be an Gaia or a Gecko issue?

The toast is actually not seen on the video because it goes below the keyboard.

Is there a way to display the toast over the keyboard because if I display it above keyboard then the space will look very much complicated because the recipient field had 20 recipient & keyboard is also shown show the size of screen left is very small.

please suggest!

Comment 16

[Gene Lian (I already quit Mozilla)]

From the point of view of back-end, the MMS' spec allows to send a single MMS to multiple receivers in one transaction. For SMS, it doesn't have this kind of concept because the SMS' spec only allows us to send one SMS to one receiver at one time. So, in the current design, if we want to send SMS to multiple receivers, the RIL will send them separately, which means we can send arbitrary number of SMS.

Can we just disable the send button only if the message wants to be sent as MMS (after attaching files or subject) and to be sent to more than 20 receivers?

I somehow agree to restrict the SMS to the limitation of 20 receivers on the UI (although the back-end doesn't have that limitation), if we want to make the UI behaviour more consistency. It's up to the UI/UX design.

Comment 17

[ankit93040]

I ll try with :gene as you have said & let you know - Can we just disable the send button only if the message wants to be sent as MMS (after attaching files or subject) and to be sent to more than 20 receivers?

Comment 18

[Julien Wajsberg [:julienw]]

Ankit, we need Ayman's feedback before further work, so that we don't end up with doing it all again. Hope you understand, thanks.

Gene, here is a question for you :

(In reply to Gene Lian [:gene] (PTO Dec. 25 ~ Jan. 5) from comment #16)
> From the point of view of back-end, the MMS' spec allows to send a single
> MMS to multiple receivers in one transaction. For SMS, it doesn't have this
> kind of concept because the SMS' spec only allows us to send one SMS to one
> receiver at one time. So, in the current design, if we want to send SMS to
> multiple receivers, the RIL will send them separately, which means we can
> send arbitrary number of SMS.
> 
> Can we just disable the send button only if the message wants to be sent as
> MMS (after attaching files or subject) and to be sent to more than 20
> receivers?
> 
> I somehow agree to restrict the SMS to the limitation of 20 receivers on the
> UI (although the back-end doesn't have that limitation), if we want to make
> the UI behaviour more consistency. It's up to the UI/UX design.

Gene, I was leaning to the opposite direction: make the MMS API accept any number of recipients, and have the MMS Gecko API send several MMS if there is more than 20 recipients. Like it's done for the SMS API...

I also think we need a user feedback in Gaia for this (like we have for the multiple segments case), but I don't think we should restrict the number of recipients a user can send to.

More generally, here is how the SMS API work:
* several recipients: the SMS API is sending several messages and returns an array of request. BTW doing the same for MMS will lead to a more consistent API, and therefore a more consistent client code.
* several segments: the SMS API is sending several messages.

Gaia is not doing anything for this, and I think the case we currently have is exactly the same.

What do you think?

Comment 19

[Julien Wajsberg [:julienw]]

Comment on attachment 8358228 [details]
VID_0005.3gp

I don't see anything meaningful in this video. Anyway, we need to wait for Ayman before doing further work. Thanks!

Comment 20

[Gene Lian (I already quit Mozilla)]

(In reply to Julien Wajsberg [:julienw] from comment #18)
> Gene, I was leaning to the opposite direction: make the MMS API accept any
> number of recipients, and have the MMS Gecko API send several MMS if there
> is more than 20 recipients. Like it's done for the SMS API...

This is not a good idea due to the threading issue. For SMS, it's fine, because we'll create multiple threads for multiple receivers separately. However for MMS, this could be a big issue. For example, if we're sending MMS to 18 receivers, then this MMS will be assigned to a thread that includes those 18 receivers. If we're sending MMS to 22 receivers, how to decide the threads if the MMS will split up to more than one MMS?

Comment 21

[Julien Wajsberg [:julienw]]

Since we don't do group MMS at reception, we could just do like before: one thread with everybody. Only the sending process would be different.

Comment 22

[Gene Lian (I already quit Mozilla)]

Do you mean sending separate MMS to each single one? That would cause a lot money... Sending *one* MMS to 20 receivers and sending *20* MMS to each receiver are totally different. We should avoid that even if we can group them into the same thread.

Comment 23

[Julien Wajsberg [:julienw]]

No, no, of course that's not what I meant :)

Concrete case: the user wants to send a MMS to 22 recipients.
* Gaia calls sendMMS with 22 recipients
* Gecko sends one MMS with 20 recipients and one MMS with 2 recipients
* but Gecko keeps one thread with 22 recipients
* Gecko sends back an array with 2 DOMRequests

Comment 24

[Gene Lian (I already quit Mozilla)]

Hmm... sounds interesting. Sorry for misunderstanding.

However, this means each of the receivers (#1 ~ #20) will receive an MMS with 20 receivers, but each of the receivers (#21 ~ #22) will receive an MMS with only 2 receivers. These two groups will have different receiver sets, which makes receivers pretty confused.

Comment 25

[Julien Wajsberg [:julienw]]

Yep, I agree this is the downside.

Comment 26

[ankit93040]

So finally what is the conclusion?

From Gaia or Gaia we should make the change?

Comment 27

[Gene Lian (I already quit Mozilla)]

I'd prefer adding a prompt or something at Gaia when users want to send MMS to more than 20 receivers, as suggested at comment #7.

Comment 28

[Julien Wajsberg [:julienw]]

Ankit, Ayman is the guy who does the UX Design for the SMS app and he will do the final sugegstion.

Comment 29

[Julien Wajsberg [:julienw]]

Omega, Jenny, can you please have a look at this bug? It would be nice to move forward.

We also saw that some operators limit to 10 recipients, so maybe we should also limit to 10 recipients instead of 20, or make this SIM dependent.

Comment 30

[Jenny Lee]

Hello Julien, I don't think it's necessary to limit the number of recipient. User should be able to send a single MMS to as many people as he wishes, ex. sending a Merry Xmas message with a photo to multiple friends (more than 20) during the holiday is pretty common. If there's a special request coming from operator or partner, we'll allow them customize.

Comment 31

[Julien Wajsberg [:julienw]]

Jenny, the problem is that there is an operator limit for MMS: we can't have more than 20 recipients in one MMS (and maybe 10 for some operators).

So currently, if you try to send a group MMS to more than 20 persons, you'll get an error.

Sending several text messages is not an issue though.

Comment 32

[Jenny Lee]

Hello Julien, is there a way to know the number of recipient limit for MMS in advance? Is the limit always 20 or 10?
We should definitely create a flow/UI to support limiting any number of recipient and what to do when user wishes to send the message to more people, but I don't think it makes sense to preset the recipient limit to a fixed number.

Comment 33

[Julien Wajsberg [:julienw]]

I think it's fixed for a carrier, but I'm not so sure. I think the MMS spec says "20" but we've seen a case where the operator was failing at "10" (I think it's AT&T in the USA).

Bevis, would you know?

Comment 34

[Bevis Tseng[:bevis][:btseng](Exited)]

(In reply to Julien Wajsberg [:julienw] from comment #33)
> I think it's fixed for a carrier, but I'm not so sure. I think the MMS spec
> says "20" but we've seen a case where the operator was failing at "10" (I
> think it's AT&T in the USA).
> 
> Bevis, would you know?

No, 
I've the same understanding that this depends on how carrier configure their MMSC.
(As what we seen in bug 1011689, the maximal recipients in AT&T is 10.)

This has to be configured per carrier for instead. :(

Comment 35

[Julien Wajsberg [:julienw]]

Beatriz, is it something that you'd like to have and can configure if we do the development?

Comment 36

[Beatriz Rodríguez [:brg]]

(In reply to Julien Wajsberg [:julienw] (PTO 08/19 -> 09/15; contact schung for SMS matters) from comment #35)
> Beatriz, is it something that you'd like to have and can configure if we do
> the development?
No, we do not have any requirement here. We are following the specs (max 20). Sorry for my delay response.

Comment 37

[Julien Wajsberg [:julienw]]

ok, let's assume 20 as a maximum.

So now, what should we do? Should we send several MMS, or should we show a banner and prevent adding more recipients?

Comment 38

[Jenny Lee]

The concept of sending out multiple MMS at the same time is fairly complicated, also I'm assuming we can't know how the operator treat the MMSs? so 20 recipients can mean 20 MMSs, or 1 MMS. To keep things simple, I think we should just limit the recipient number to 20 (this number seems to be the conclusion), show a banner that says "Limited to 20 recipients" and prevent user from typing more names. Thanks!

Comment 39

[Julien Wajsberg [:julienw]]

(In reply to Jenny Lee from comment #38)
> The concept of sending out multiple MMS at the same time is fairly
> complicated, also I'm assuming we can't know how the operator treat the
> MMSs?

No, if we ask to send one MMS, the operator will send one MMS only _or_ report an error.
If we ask more than 20 (or 10 for AT&T) recipients, we get an error (that's what happens now).

> so 20 recipients can mean 20 MMSs, or 1 MMS.

so, no :) it will always be either 1 MMS or no MMS !

> To keep things simple, I
> think we should just limit the recipient number to 20 (this number seems to
> be the conclusion), show a banner that says "Limited to 20 recipients" and
> prevent user from typing more names. Thanks!

NI to see if you still think the same with the additional information.

I also think this is the simplest solution :)

Comment 40

[Jenny Lee]

No change of mind ;) Let's go with the simple solution!

Comment 42

[Julien Wajsberg [:julienw]]

Mass closing of Gaia::SMS bugs. End of an era :(

Comment 43

[Julien Wajsberg [:julienw]]

Mass closing of Gaia::SMS bugs. End of an era :(