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

RESOLVED WONTFIX

Status

Firefox OS
Gaia::SMS
P2
normal
RESOLVED WONTFIX
4 years ago
11 months ago

People

(Reporter: sync-1, Unassigned)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

4 years ago
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:

Updated

4 years ago
blocking-b2g: --- → leo?

Updated

4 years ago
Summary: [Buri][shari][T-mobile 51602][MMS]Incoming MMS messages without a given sender address are stored in a thread with an untranslated label "anonymous" → [Buri][shira-51602][MMS]Incoming MMS messages without a given sender address are stored in a thread with an untranslated label "anonymous"
Hi,

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

Thanks !
(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.
blocking-b2g: leo? → -
Vicamo, could you please explain how this could happen in real-life ? Should we add code to translate "anonymous" ?

Thanks !
Flags: needinfo?(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.
Flags: needinfo?(vyang)
blocking-b2g: - → 1.3?
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).
Flags: needinfo?(vyang)
Flags: needinfo?(aymanmaat)

Comment 6

4 years ago
(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 sync-1@bugzilla.tld is asking is that the word "anonymous" is translated into the local language, German, which would be "Unbekannt".


ni? to sync-1@bugzilla.tld to confirm or correct what i have written here
Flags: needinfo?(aymanmaat) → needinfo?(sync-1)
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 ?
Flags: needinfo?(aymanmaat)

Comment 8

4 years ago
(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 sync-1@bugzilla.tld as i have clarity regarding comment 6.
Flags: needinfo?(aymanmaat) → needinfo?(felash)

Updated

4 years ago
Flags: needinfo?(sync-1)
I'd say they can't, but Vicamo can have a more definite answer.

Vicamo, please see question in comment 8
Flags: needinfo?(felash)

Comment 10

4 years ago
(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.
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.
see previous comment
Flags: needinfo?(aymanmaat)
(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.
Flags: needinfo?(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}".
Vicamo, can you tell us again what has changed when we disabled groupmms ? I can't recall correctly...
Flags: needinfo?(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
Flags: needinfo?(vyang)

Comment 17

4 years ago
Created attachment 813108 [details]
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)
Flags: needinfo?(aymanmaat) → needinfo?(tyler.altes)

Comment 18

4 years ago
> 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. :)
triage: not blocking any release. please land it in master directly when a patch is available
blocking-b2g: 1.3? → ---
Flags: needinfo?(tyler.altes)

Comment 20

4 years ago
Created attachment 822332 [details]
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
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 !
Flags: needinfo?(btseng)
(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 !
Flags: needinfo?(btseng)
OK great !

and another question for you Bevis: do you put these messages in the same thread ?
Flags: needinfo?(btseng)
(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.
Flags: needinfo?(btseng)
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 !
Flags: needinfo?(bmao)
Move to firefox project. Still, let me know if there are any UX emergency.
Flags: needinfo?(bmao)
Mass closing of Gaia::SMS bugs. End of an era :(
Status: NEW → RESOLVED
Last Resolved: 11 months ago
Resolution: --- → WONTFIX
Mass closing of Gaia::SMS bugs. End of an era :(
You need to log in before you can comment on or make changes to this bug.