916440 - [Buri][shira-51602][MMS]Incoming MMS messages without a given sender address are stored in a thread with an untranslated label "anonymous"

Status: RESOLVED WONTFIX

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

Description

[sync-1]

Mozilla build ID:20130902041201
 DEFECT DESCRIPTION:
  Incoming MMS messages without a given sender address (no from field) are stored in a thread with an untranslated label "anonymous". Instead the thread should be labeled for example with "Unbekannt".
 
  REPRODUCING PROCEDURES:
 
  EXPECTED BEHAVIOUR:
 
  ASSOCIATE SPECIFICATION:
 
  TEST PLAN REFERENCE:
 
  TOOLS AND PLATFORMS USED:
 
  USER IMPACT:
 
  REPRODUCING RATE:
 
  For FT PR, Please list reference mobile's behavior:

Comment 1

[Julien Wajsberg [:julienw]]

Hi,

Could you please tell us how/when this can happen ?

Thanks !

Comment 2

[bhavana bajaj [:bajaj]]

(In reply to sync-1 from comment #0)
> Mozilla build ID:20130902041201
>  DEFECT DESCRIPTION:
>   Incoming MMS messages without a given sender address (no from field) are
> stored in a thread with an untranslated label "anonymous". Instead the
> thread should be labeled for example with "Unbekannt".
>  
>   REPRODUCING PROCEDURES:
>  
>   EXPECTED BEHAVIOUR:
>  
>   ASSOCIATE SPECIFICATION:
>  
>   TEST PLAN REFERENCE:
>  
>   TOOLS AND PLATFORMS USED:
>  
>   USER IMPACT:
>  
>   REPRODUCING RATE:
>  
>   For FT PR, Please list reference mobile's behavior:

Don't think this is a common day-day scenario one can experience, so not a blocker.If you have steps that a user can come into this situation, then it resolves to a missing translation.

Comment 3

[Julien Wajsberg [:julienw]]

Vicamo, could you please explain how this could happen in real-life ? Should we add code to translate "anonymous" ?

Thanks !

Comment 4

[Vicamo Yang [:vicamo][:vyang]]

(In reply to Julien Wajsberg [:julienw] from comment #3)
> Vicamo, could you please explain how this could happen in real-life ? Should
> we add code to translate "anonymous" ?
> 
> Thanks !

From OMA-TS-MMS_ENC-V1_3-20110913-A, both table 3 "Header fields of M-Notification.ind PDU" and table 5 "Header fields of M-Retrieve.conf PDU", the "From" header field is not a mandatory one and the description column has:

  If hiding the address of the sender from the recipient is requested by the
  originating MMS Client and supported and accepted by the MMS Proxy-Relay,
  the MMS Proxy-Relay MUST NOT add this field to the M-Notification.ind PDU.

Above lines refer to the optional "X-Mms-Sender-Visibility" header field in M-Send.req PDU.  So, this is possible from protocol's point of view.

Comment 5

[Julien Wajsberg [:julienw]]

Vicamo, the "anonymous" name is set by the gecko mobile message api then ? Is it spec somewhere ? Is it RIL dependant ?

I think it would be better to have a sender set to `null` than "anonymous" in that case, and of course handle it properly in Gaia (with Ayman's UX help).

Comment 6

[ayman maat :maat]

(In reply to Julien Wajsberg [:julienw] from comment #5)
> Vicamo, the "anonymous" name is set by the gecko mobile message api then ?
> Is it spec somewhere ? Is it RIL dependant ?
> 
> I think it would be better to have a sender set to `null` than "anonymous"
> in that case, and of course handle it properly in Gaia (with Ayman's UX
> help).

I actually read this as bug being a language localisation issue.

"Unbekannt" in German = "unknown" in english.. which could also be termed as "anonymous" which is what we are using now.

I think what [e-mail] is asking is that the word "anonymous" is translated into the local language, German, which would be "Unbekannt".


ni? to [e-mail] to confirm or correct what i have written here

Comment 7

[Julien Wajsberg [:julienw]]

Ayman> completely agree with you about the original bug. My question for you was more: do you think all messages without sender should end up in the same "anonymous" thread ?

Comment 8

[ayman maat :maat]

(In reply to Julien Wajsberg [:julienw] from comment #7)
> Ayman> completely agree with you about the original bug. My question for you
> was more: do you think all messages without sender should end up in the same
> "anonymous" thread ?

ah. ok. well, i require a little more info before i could clearly answer that. My question would be (and i am pretty damn certain i know the answer to this, but just want to be totally certain): when the user receives a message from an "anonymous" contact... can they reply to it? 

- ni? to Julien
- removing my ni? to [e-mail] as i have clarity regarding comment 6.

Comment 9

[Julien Wajsberg [:julienw]]

I'd say they can't, but Vicamo can have a more definite answer.

Vicamo, please see question in comment 8

Comment 10

[ayman maat :maat]

(In reply to Julien Wajsberg [:julienw] from comment #9)
> I'd say they can't, but Vicamo can have a more definite answer.
> 
> Vicamo, please see question in comment 8

Ok, well, to speed things up a bit my thinking is that if the user cannot replay to an anonymous message (i would be surprised if they could) we can bunch all anonymous messages together in a single thread just to clean up the end users inbox. Rationale is that if the user done not know who the message is from and cannot reply to it we might as well package them all together in a single thread rather than littering their inbox with individual anonymous messages.

Again, i am happy to hear thoughts if anyone disagrees or has further information that might influence a change on this design decision.

Comment 11

[Julien Wajsberg [:julienw]]

Ayman> I agree with this, but I don't think this thread should be called "anonymous". And maybe we need to remove or disable the composer part.

Comment 12

[Julien Wajsberg [:julienw]]

see previous comment

Comment 13

[Vicamo Yang [:vicamo][:vyang]]

(In reply to Julien Wajsberg [:julienw] from comment #5)
> Vicamo, the "anonymous" name is set by the gecko mobile message api then ?
> Is it spec somewhere ? Is it RIL dependant ?

Yes, it's set by MmsService in Gecko[1].

> I think it would be better to have a sender set to `null` than "anonymous"
> in that case, and of course handle it properly in Gaia (with Ayman's UX
> help).

So how do we search these messages?

(In reply to ayman maat :maat from comment #8)
> ah. ok. well, i require a little more info before i could clearly answer
> that. My question would be (and i am pretty damn certain i know the answer
> to this, but just want to be totally certain): when the user receives a
> message from an "anonymous" contact... can they reply to it?

MMS, just like SMS, has no "REPLY" concept.  Every message is an independent transaction in protocol's point of view.  The REPLY concept we implement is actually sending a message to some recipients who appear in a specific message.  So REPLY is SEND basically.

According to MMS-CONF, the union set of TO/CC/BCC must not be empty[2], so you can't send somebody a MMS without his name etched in the outgoing PDU.  And since we don't know the sender (or "from", in MMS spec's terminology) address of an anonymous MMS message, we can't send a MMS message to him alone.  We can still send a message to other recipients, if any, of that anonymous message.

  <anonymous>  --(TO)-> A, B, C
  B, C         <-(TO)-- A

[1]: http://mxr.mozilla.org/mozilla-central/source/dom/mobilemessage/src/gonk/MmsService.js#1291
[2]: don't have documents at hand, but both MMS-ENC and MMS-CONF have this rule.

Comment 14

[Vicamo Yang [:vicamo][:vyang]]

(In reply to ayman maat :maat from comment #10)
> (In reply to Julien Wajsberg [:julienw] from comment #9)
> > I'd say they can't, but Vicamo can have a more definite answer.
> > 
> > Vicamo, please see question in comment 8
> 
> Ok, well, to speed things up a bit my thinking is that if the user cannot
> replay to an anonymous message (i would be surprised if they could) we can
> bunch all anonymous messages together in a single thread just to clean up
> the end users inbox.

But what should we do when there are multiple recipients in that anonymous message?  We now identify a thread by "sender U {recipients}".

Comment 15

[Julien Wajsberg [:julienw]]

Vicamo, can you tell us again what has changed when we disabled groupmms ? I can't recall correctly...

Comment 16

[Vicamo Yang [:vicamo][:vyang]]

(In reply to Julien Wajsberg [:julienw] from comment #15)
> Vicamo, can you tell us again what has changed when we disabled groupmms ? I
> can't recall correctly...

In |MobileMessageDatabaseService.js| function |saveReceivedMessage|[1], we disabled populating thread participants with other recipients in a received MMS message.  That is, all received MMS messages are treated as those have only one recipient, so we don't have to explicitly pick user himself up, we can just ignore all the recipients.  For example:

  A --> B, C, myself

is treated as:

  A --> myself

while you can still see all the recipients in MmsMessage, the thread record created for this message has only A in participants attribute.

[1]: https://mxr.mozilla.org/mozilla-central/source/dom/mobilemessage/src/gonk/MobileMessageDatabaseService.js#1366

Comment 17

[ayman maat :maat]

Attachment: FFOS_AnonymousMessage_2013101_V0.1.pdf

(In reply to Julien Wajsberg [:julienw] (PTO today) from comment #11)
> Ayman> I agree with this, but I don't think this thread should be called
> "anonymous". And maybe we need to remove or disable the composer part.

Sorry for the delay in responding. I have been trying to find a way to send messages between my phones anonymously in order to benchmark behaviour, but have been completely unsuccessful... therefore am just going to have to propose something based purely on design pragmatism. I would propose:

1) we group all 'anonymous' messages together in a single thread just to clean up the end users inbox. 
2) the thread should be titled 'unknown sender' or something like that that is more appropriate than 'anonymous'.
3) Julien, you are correct, as the user cannot reply to 'anonymous' messages so we should disable and hide the keyboard and the message composer, send and attach CTAs
4) However we need to orientate the user as to why they cannot reply so we should provide a message at the bottom of the screen informing them why they cannot reply to these messages.

Refer to attached wireframe which if there are no alterations (apart from language) required I will publish in the next addition of the message app wireframes. 

ni? to Tyler to propose more humane language than i am capable of thinking of for point 2) and 4)

Comment 18

[tyler.altes]

> 2) the thread should be titled 'unknown sender' or something like that that
> is more appropriate than 'anonymous'.

Yes, I think "Unknown sender" is an appropriate name for this. 


> 4) However we need to orientate the user as to why they cannot reply so we
> should provide a message at the bottom of the screen informing them why they
> cannot reply to these messages.

Here is where my confusion begins. I don't understand why the user cannot reply. More importantly, if they don't know who the sender is, and they are not able to respond even to ask who it is... why would this message be delivered to them in the first place? It seems to be a case that only causes confusion for the user. If someone will explain it to me, I'll do my best to explain it to the user. :)

Comment 19

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

triage: not blocking any release. please land it in master directly when a patch is available

Comment 20

[ayman maat :maat]

Attachment: FFOS_MessageApp_V1.3_20121025_V5.0.pdf

**Release Note**

new wireframes
- none

updated wireframes
- none

deleted wireframes
- none

new flows
- Forward Message : Message from thread
- Delivery / Read report : Setting reports from within phone settings
- Delivery / Read report : Setting reports from message app inbox
- Delivery / Read report : Setting reports from within new message
- Delivery / Read report : Setting reports from within message thread
- Delivery / Read report : View report from thread
- Delivery / Read report : View delivery report from notification
- Delivery / Read report : View read report from notification
- Message Module Interactions : Long press and MMS
- Message Module Interactions : Tap on email address and MMS
- Message Module Interactions : Tap on url and MMS
- Message Module Interactions : Tap on phone number and MMS
- Anonymous messages : Thread

updated flows
- none

deleted flows
- none

pages relevant to this bug: 26-27

Comment 21

[Julien Wajsberg [:julienw]]

Hey Bevis,

do you know if we still save a message in a "anonymous" thread now, if that message has no sender ? I can't find the "anonymous" string in dom/mobilemessage.

Thanks !

Comment 22

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

(In reply to Julien Wajsberg [:julienw] (PTO -> 2016) from comment #21)
> Hey Bevis,
> 
> do you know if we still save a message in a "anonymous" thread now, if that
> message has no sender ? I can't find the "anonymous" string in
> dom/mobilemessage.
No, we don't. 
There will be an empty string "" in MmsMessage.sender [1] which causes a [""] presented in MobileMessageThread.participants. :-)

BTW, for SmsMessage, the sender address will always be valid.

[1] https://hg.mozilla.org/mozilla-central/annotate/5644818538de2413cce52551e32b025e6c7e352e/dom/mobilemessage/gonk/MobileMessageDB.jsm#l3332
> 
> Thanks !

Comment 23

[Julien Wajsberg [:julienw]]

OK great !

and another question for you Bevis: do you put these messages in the same thread ?

Comment 24

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

(In reply to Julien Wajsberg [:julienw] (PTO -> 2016) from comment #23)
> OK great !
> 
> and another question for you Bevis: do you put these messages in the same
> thread ?

Yes! I also verified this locally and they were belonging to the same thread.

Comment 25

[Julien Wajsberg [:julienw]]

OK great, so it should be possible to work on this.

Bryant, can you review the spec in comment 20 and tell me if this still looks OK ? The spec for this bug in the last page of the spec.

Thanks !

Comment 26

[Bryant Mao [:bryantmao]]

Move to firefox project. Still, let me know if there are any UX emergency.

Comment 27

[Julien Wajsberg [:julienw]]

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

Comment 28

[Julien Wajsberg [:julienw]]

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