880628 - [MMS/SMS] Multi-recipient. Allow manual entry of duplicate recipients

Status: VERIFIED FIXED

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

Description

[isabelrios]

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

PROCEDURE
1.Create a new SMS/MMS
2.Tap on `+` icon to add a recipient, repeat this to have several recipients
3.Then try to add a contact which was already added into the 'To' field

EXPECTED
As it was specified, user should be able to add the same contact several times into the 'To' field

ACTUAL
When tapping on a contact which has been already added, user is taken back to SMS/MMS compose view, the contact is not added into the 'To' field and there is not any error or warning message to let user know why the contact has not been added

Comment 1

[Stephany Wilkes]

Ayman, can you please clarify the expected behavior? Thanks!

Comment 2

[Rick Waldron [:rwaldron]]

The behaviour of FFOS Messages app exactly matches iOS Messaging and Android (In reply to Isabel Rios [:isabel_rios] from comment #0)
> Bug seen on Unagi v1-train
> Gecko-65bbcee
> Gaia-13c6246
> 
> PROCEDURE
> 1.Create a new SMS/MMS
> 2.Tap on `+` icon to add a recipient, repeat this to have several recipients
> 3.Then try to add a contact which was already added into the 'To' field
> 
> EXPECTED
> As it was specified, 


Where? I cannot find such specification in v8.0 WF document.


> user should be able to add the same contact several
> times into the 'To' field

The behaviour of FFOS Messages app exactly matches iOS Messaging and Android 

> 
> ACTUAL
> When tapping on a contact which has been already added, user is taken back
> to SMS/MMS compose view, the contact is not added into the 'To' field and
> there is not any error or warning message to let user know why the contact
> has not been added

Yes, in exactly the same way that iOS Messaging and Android Messaging behave.

Comment 3

[ayman maat :maat]

(In reply to Rick Waldron from comment #2)
> The behaviour of FFOS Messages app exactly matches iOS Messaging and Android
> (In reply to Isabel Rios [:isabel_rios] from comment #0)
> > Bug seen on Unagi v1-train
> > Gecko-65bbcee
> > Gaia-13c6246
> > 
> > PROCEDURE
> > 1.Create a new SMS/MMS
> > 2.Tap on `+` icon to add a recipient, repeat this to have several recipients
> > 3.Then try to add a contact which was already added into the 'To' field
> > 
> > EXPECTED
> > As it was specified, 
> 
> 
> Where? I cannot find such specification in v8.0 WF document.

guidance on the addition of multiple instances of the same contact can be found on page 07: 

"
Selection of same result
A user selects a contact with a given channel of communication (say telephone number) from the auto suggestions in order to add them to the ‘to’ field. If they then proceed to generate the same list of auto suggestions a second time the number already selected will still be presented. If the user then selects the same contact with the same channel of communication from the suggestions a second time in order to add to the ‘to’, the ‘to’ field will contain two individual entries for the same contact with same channel of communication. However when the user presses ‘send’ only one message should be sent to the contact.
"

Though this is talking about auto suggestions by extrapolation the principle should be implemented for any other method that a user can enter a destination into the 'to' field. 

N.B. i just noticed that a section of annotation 02 is content left over from a previous version of the document and is a publishing error. I am lead to believe that part of what annotation 2 is specifying is unachievable due to effect on performance. It has already been removed from the next edition of the document

> 
> 
> > user should be able to add the same contact several
> > times into the 'To' field
> 
> The behaviour of FFOS Messages app exactly matches iOS Messaging and Android 
> 
> > 
> > ACTUAL
> > When tapping on a contact which has been already added, user is taken back
> > to SMS/MMS compose view, the contact is not added into the 'To' field and
> > there is not any error or warning message to let user know why the contact
> > has not been added
> 
> Yes, in exactly the same way that iOS Messaging and Android Messaging behave.

At this point I think it is important to clarify a couple of things:

Firstly we are not designing or developing any other OS other than FirefoxOS
Secondly no other mobile OS exists as a UX specification for the design and development of FirefoxOS. The only UX specifications that you should be following or using for guidance are the ones that are made available specifically for this project. If the solution in the specifications that are delivered to you is ambiguous, conflicting, deficient, unachievable or in your professional opinion suboptimal you should be contacting the published of this specifications directly though any of the available communication channels, looping in whoever else need to be in on the conversation, raising your concerns and then working with them to define a solution. It is not acceptable to simply refer to another OS for a solution and copy the observed behavior.
Thirdly, regarding what you have implemented: The unexpected and unnotified deletion of content the user has just input into the system is extremely bad UX. Irrespective of where else you have observed it, its just wrong. It also deviates from the behavior that was specified in HTML5_SMS-MMSUserStorySpecifications_20130503_V8.0 and in view of this needs correcting. 

If you need any further clarification please do not hesitate to contact me

Comment 4

[Rick Waldron [:rwaldron]]

(In reply to ayman maat :maat from comment #3)
>  I am lead to believe that part of what annotation 2 is specifying is unachievable due to effect on performance. It has already been removed from the next edition of the document

I'm not sure what your sources for this are, but as the implementor of multi-recipient, I can say with complete confidence that this is a very low cost operation.




Sidenote: specifications/wireframes without addressable, numbered points are "extremely bad UX".

Comment 5

[Rick Waldron [:rwaldron]]

Attachment: Github Pull Request

Comment 6

[ayman maat :maat]

Awesome! works fine for me. Thanks for your cooperation and feedback Rick.

Comment 7

[ayman maat :maat]

Comment on attachment 762085 [details] [review]
Github Pull Request

Awesome! works fine for me. Thanks for your cooperation and feedback Rick.

Comment 8

[Julien Wajsberg [:julienw]]

Comment on attachment 762085 [details] [review]
Github Pull Request

Corey can probably review this faster than me

Comment 9

[Corey Frang [:gnarf]]

Comment on attachment 762085 [details] [review]
Github Pull Request

r=me

Comment 10

[Rick Waldron [:rwaldron]]

Landed https://github.com/mozilla-b2g/gaia/commit/4ff9f94fdc607209bf57b4843a8102229db147e7

Comment 11

[John Ford [:jhford] CET/CEST Berlin Time]

I was not able to uplift this bug to v1-train.  If this bug has dependencies which are not marked in this bug, please comment on this bug.  If this bug depends on patches that aren't approved for v1-train, we need to re-evaluate the approval.  Otherwise, if this is just a merge conflict, you might be able to resolve it with:

  git checkout v1-train
  git cherry-pick -x  4ff9f94fdc607209bf57b4843a8102229db147e7
  <RESOLVE MERGE CONFLICTS>
  git commit

Comment 12

[Rick Waldron [:rwaldron]]

https://github.com/mozilla-b2g/gaia/pull/10445

Comment 14

[John Ford [:jhford] CET/CEST Berlin Time]

(In reply to Rick Waldron from comment #12)
> https://github.com/mozilla-b2g/gaia/pull/10445

Github is saying that this no longer applies to v1-train.

Comment 15

[Corey Frang [:gnarf]]

uplifted master: 4ff9f94fdc607209bf57b4843a8102229db147e7
to v1-train: 3c11025e78e97baef1649e3b0c98d02899680133

Comment 16

[Corey Frang [:gnarf]]

also uplifted master: 74fb3b1dd864cf090a26a578615064cd9130f5e8
to v1-train: e44308ce54fa049b6361d303850fbd172ba592fe

Comment 17

[Corey Frang [:gnarf]]

Rick - In the future, if a bug includes a follow up commit - PLEASE make sure that both commits are referenced in bugzilla - thanks!

Comment 18

[John Ford [:jhford] CET/CEST Berlin Time]

1.1hd: e44308ce54fa049b6361d303850fbd172ba592fe

Comment 19

[isabelrios]

Verified with unagi device 07/07 build:
Gecko-e7708d4
Gaia-d336288
Ref. ril

Comment 20

[sbogati]

Issue as expected on the Leo

Build ID: 20130731070208
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/aff662053ee8
Gaia: 6c635e809baedb6b3393bd351b8ce95304782ac6
Platform Version: 18.1
RIL Version: 01.01.00.019.171
As it was specified, user was able to add the same contact several times into the 'To' field