925404 - [B2G] [SMS] Always include the phone number in the SMS Thread UI, even if the carrier is known

Status: VERIFIED FIXED

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

Description

[Chris Kreinbring [:CKreinbring]]

Attachment: Screenshot of contact info

Description:
After sending a text to a contact with just the name and number with carrier, the carrier name is shown instead of the phone number.

Repro Steps:
1) Update Buri to Build ID: 20131010004001
2) Have a contact with a name, phone number and carrier.
3) Launch the Messaging app.
4) Send an SMS to the contact.
5) Observe the secondary info line below the title.

Actual:
The phone type and carrier is shown.

Expected:
The phone type and number is shown.

Environmental Variables
Device: Buri 1.2 mozilla RIL
Build ID: 20131010004001
Gecko: http://hg.mozilla.org/releases/mozilla-aurora/rev/3f16dc100b1f
Gaia: 51f3c79ea93bb91d3b12e50b49d203a049a94a9b
Platform Version: 26.0a2

Notes:
Repro frequency: 100%
Link to failed test case: https://moztrap.mozilla.org/manage/cases/?filter-id=5030
See attached screenshots

Comment 1

[Chris Kreinbring [:CKreinbring]]

Attachment: Screenshot of SMS thread

Comment 2

[Rick Waldron [:rwaldron]]

Attachment: 925404-1.png

Comment 3

[Rick Waldron [:rwaldron]]

Attachment: 925404-2.png

Comment 4

[Rick Waldron [:rwaldron]]

Attachment: 925404-3.png

Comment 5

[Rick Waldron [:rwaldron]]

This isn't a regression. Please review the explicitly defined rules as provided by Ayman here: https://bugzilla.mozilla.org/show_bug.cgi?id=883911#c4

Specifically citing:

> 1) …a unique string in the <carrier> field and a unique string in the <type> field output:
>	<type>, <carrier>


Which is what is shown in both the OP attachments and my follow attachments

Comment 6

[Jason Smith [:jsmith]]

I disagree with the UX proposal cited. Users are less likely to care about the carrier they are sending their SMS to - they certainly do want to know the phone number they are sending their text to. Otherwise, they could make a mistake and potentially send a SMS to the right contact name, but the wrong phone number, because they didn't remember how the type of contact mapped onto a phone number. In fact, the most important information to convey here is the phone number - the other pieces of information are nice to haves at best.

Comment 7

[Stephany Wilkes]

Flagging Jacqueline.

Comment 8

[Rick Waldron [:rwaldron]]

(In reply to Jason Smith [:jsmith] from comment #6)
> I disagree with the UX proposal cited. Users are less likely to care about
> the carrier they are sending their SMS to - they certainly do want to know
> the phone number they are sending their text to. Otherwise, they could make
> a mistake and potentially send a SMS to the right contact name, but the
> wrong phone number, because they didn't remember how the type of contact
> mapped onto a phone number. In fact, the most important information to
> convey here is the phone number - the other pieces of information are nice
> to haves at best.

You may disagree, but it's not up to us to make this call. NI? Ayman, as he is the one that designed the feature and should provide guidance here.

Comment 9

[Stephany Wilkes]

Jacqueline is the lead Mozilla UX person on Comms. She will make the call.

Comment 10

[ayman maat :maat]

(In reply to Rick Waldron from comment #8)
> (In reply to Jason Smith [:jsmith] from comment #6)
> > I disagree with the UX proposal cited. Users are less likely to care about
> > the carrier they are sending their SMS to - they certainly do want to know
> > the phone number they are sending their text to. Otherwise, they could make
> > a mistake and potentially send a SMS to the right contact name, but the
> > wrong phone number, because they didn't remember how the type of contact
> > mapped onto a phone number. In fact, the most important information to
> > convey here is the phone number - the other pieces of information are nice
> > to haves at best.
> 
> You may disagree, but it's not up to us to make this call. NI? Ayman, as he
> is the one that designed the feature and should provide guidance here.

...Its not even up to UX to make this call. Displaying carrier has been a hard requirement that has been in place since the very beginning of this project. We are not in a position to change that until the requirement is changed by product.

Marking as invalid. behaviour is aligned to requirements and is as specified.

Comment 11

[Jason Smith [:jsmith]]

I don't think that dismisses the fact of why phone number is being shown if the carrier is required to be shown. Please discuss this with product and explain to me exactly why the phone number cannot be shown in the use case specified. As it stands right now, it does not make sense to me why you would not tell user what phone number they are sending a text to.

Comment 12

[Jason Smith [:jsmith]]

needinfo on product for comment 11

Comment 13

[Julien Wajsberg [:julienw]]

The exact rule is:
* we use carrier if the "carrier" has been filled in, otherwise we use the phone number
* we still use the phone number if the "carrier" has been filled in, but the contact has two numbers with the same "carrier" information

We assumed that as long as the user enters a carrier information for a contact's number, this is what's important for him. If he really wants to know the phone number he can still tap on the header and show the contact's information.

Won't close the bug again but I think exactly like Rick and Ayman here.

Comment 14

[Stephany Wilkes]

Flagging Wilfred and Sandip, specifically, to address this more quickly.

Comment 15

[Jason Smith [:jsmith]]

Clearing the general needinfo on the product email alias as there's needinfo on the relevant product managers already.

Comment 16

[Jason Smith [:jsmith]]

(In reply to Julien Wajsberg [:julienw] (in Paris-Web conference thursday and friday) from comment #13)
> The exact rule is:
> * we use carrier if the "carrier" has been filled in, otherwise we use the
> phone number

This I don't think is a good idea - I can't remember the last time I ever actually cared that about the carrier I was sending my text message to. I care about who I'm sending it and what number it's going to.

> * we still use the phone number if the "carrier" has been filled in, but the
> contact has two numbers with the same "carrier" information

This approach is thinking too scientifically, and less user centric. I think we need to back up and think about what our users are likely to care about vs. not to understand what to display.

> 
> We assumed that as long as the user enters a carrier information for a
> contact's number, this is what's important for him. If he really wants to
> know the phone number he can still tap on the header and show the contact's
> information.

That's not really a good assumption to make. Just because I provide the information doesn't mean I treat it as the most important information to understand. Anyways, I think the above discussion is showing that we're not thinking outside of the box here - ask yourself, what is a user really seeing as the most important information? What's less important? That justifies a UX design decision on what to include vs. not. 

Also - tapping the header isn't an obvious workflow. When I'm typing a text message, I'm going to read what's on the SMS page, not tap around to gather information.

Comment 17

[Rick Waldron [:rwaldron]]

(In reply to Jason Smith [:jsmith] from comment #16)
> (In reply to Julien Wajsberg [:julienw] (in Paris-Web conference thursday
> and friday) from comment #13)
> > The exact rule is:
> > * we use carrier if the "carrier" has been filled in, otherwise we use the
> > phone number
> 
> This I don't think is a good idea - I can't remember the last time I ever
> actually cared that about the carrier I was sending my text message to. I
> care about who I'm sending it and what number it's going to.
> 
> > * we still use the phone number if the "carrier" has been filled in, but the
> > contact has two numbers with the same "carrier" information
> 
> This approach is thinking too scientifically, and less user centric. I think
> we need to back up and think about what our users are likely to care about
> vs. not to understand what to display.

FWIW, I actually agree with this and any point that supports always displaying the phone number.

Comment 18

[Jason Smith [:jsmith]]

(In reply to Rick Waldron from comment #17)
> FWIW, I actually agree with this and any point that supports always
> displaying the phone number.

Okay, then let's do that. We should implement a fix here then that always displays the phone number, rather than not showing it in certain cases cited above. That's my root concern here, less so of the others of why we would include the carrier in the first place - although it doesn't necessarily hurt to include it, unless there's no visual real estate left. Based on the screenshot seen here though, I think there is definitely room to include the phone number.

Comment 19

[Julien Wajsberg [:julienw]]

I thought like you at first but then I learnt to trust our UX designers.

I think that the "carrier" name is badly choosen, and is more like a "text reminder". But I was told this is used a lot in our target countries.

No change should be made without Ayman's approval here anyway. Flagging him then.

Comment 20

[ayman maat :maat]

ok Jason so i have a problem here with this thread and the desire to ignore (or redefine) requirements that are defined by user research and alter the implementation based on personal opinion/desire... 

We have a hard requirement which has been in place since before V1 based off the back of user research from the south american market to display the carrier field over and above the phone number. Carrier of contacts phone (apparently) is very important to our end users in these markets as it has an impact on cost when contact is made. Its presence differentiates us, and thats why the design is the way it is.

You are by no means the first person who, without knowledge of the design reasoning, has raised a (personal) issue with displaying the carrier field ...and i very much doubt you will be the last. But until requirements are changed by product I am going to consistently block any move to alter the behaviour of the carrier field.

With reference to comment 10, marking this bug as invalid as behaviour is aligned to requirements and is as specified

adding ni? to Daniel Coloma and Noemi (product at TEF where the requirement originates from) so that they have visibility of this conversation and can contribute if they see fit.

Comment 21

[Julien Wajsberg [:julienw]]

Ayman, 2 questions:
* what do you think of having both the carrier information and the phone number ?
* what do you think of renaming the "carrier" label ?

Comment 22

[Jason Smith [:jsmith]]

I think I've made it pretty clear that QA isn't going to be okay with the proposed design TEF has for not including the phone number. Without a clear rationale for not including the phone number, I think at this point I'm going to have to escalate up my management chain to get a fix here.

Comment 23

[Jason Smith [:jsmith]]

(In reply to ayman maat :maat from comment #20)
> ok Jason so i have a problem here with this thread and the desire to ignore
> (or redefine) requirements that are defined by user research and alter the
> implementation based on personal opinion/desire... 

User research is just one set of data - we have dogfooders and QAs who pick up and use this product daily. If it doesn't make sense to them, then you need to re-evaluate.

> 
> We have a hard requirement which has been in place since before V1 based off
> the back of user research from the south american market to display the
> carrier field over and above the phone number. Carrier of contacts phone
> (apparently) is very important to our end users in these markets as it has
> an impact on cost when contact is made. Its presence differentiates us, and
> thats why the design is the way it is.

That does not make an argument by any means for why phone number shouldn't be displayed. That just argues that the carrier should be there. Anyways, there's always be differing opinions on what a user thinks is important to display when sending a text message, so I don't think that the above rationale always is going to apply globally. It's just too closed off of a view to how this should be designed.

> 
> You are by no means the first person who, without knowledge of the design
> reasoning, has raised a (personal) issue with displaying the carrier field
> ...and i very much doubt you will be the last. But until requirements are
> changed by product I am going to consistently block any move to alter the
> behaviour of the carrier field.

It isn't a personal issue - this is just common sense for how a phone should work. The reporter claimed that the phone number wasn't displaying was a bug and I agree with them. If you've received multiple complaints around this, perhaps there's a missing element of analysis here that not being met in the current design?

> 
> With reference to comment 10, marking this bug as invalid as behaviour is
> aligned to requirements and is as specified

I think the above discussion has made it clear that you can't make a final decision here. Nevertheless, the only way I'm going to get an argument to not include the phone number is to get a real solid reasoning why it shouldn't be there. I see arguments in fact for it, which makes me think that it should still be implemented.

> 
> adding ni? to Daniel Coloma and Noemi (product at TEF where the requirement
> originates from) so that they have visibility of this conversation and can
> contribute if they see fit.

Just so it's clear - you need to get agreement with multiple QAs around why the phone number should or shouldn't be there to resolve this bug. Otherwise, someone whether that be a dogfooder, a QA, etc will file this bug again, as the reporter will see it as not making sense to them.

Comment 24

[Rafael Rebolleda]

Hey folks, 

From the Product and UX perspective, and to give a bit of context and rationale:

In our target markets, customers carry around several SIM cards to make the most out of their plans, in terms of valley/peak hours and carrier matching. Thus, knowing which carrier a user is interacting with is of vital importance in their flows in order to save money. I understand that is irrelevant for most of us, according to our carrier plans and economic realities, but we're not the target user. In this context, we went to a great deal of effort back in the day both in engineering and UX to make this happen.

That said, if the info is irrelevant for anyone, they can just ignore the field and will therefore see the beloved number which, fwiw and according to another research carried around dialer, nobody actually recognizes or associates with a contact anyway, but whatever. I agree the editing of contact details could be reworked to emphasize the fact that it is an optional field, so that is something we might take a look as a separate issue.

In any case, this a requirement from Product that comes straight from research and satisfies a clear customer and business case. I can't see how dogfooding experiences, while valuable in general, match against those in this particular context. In any case, as far as QA goes, this is working as devised, agreed, spec'ed and expected.

I will defer marking it as invalid to Daniel Coloma for the sake of diplomacy.

Comment 25

[Jason Smith [:jsmith]]

Rafael - I appreciate the rationale. We discussed this a bit more offline between product, QA, and UX. There's general agreement that the carrier should be there. However, there is agreement that at least two of concerns brought up by QA about the phone number's value argues in favor of investigating whether there's value to include the phone number always on composing a message. On that regard, this is not getting flagged as invalid at this point - we're using this bug for investigating including the phone number always in the compose message UI. Let me rework the title to indicate that.

Comment 26

[Rick Waldron [:rwaldron]]

(In reply to Jason Smith [:jsmith] from comment #25)
> we're using this bug for investigating including the phone
> number always in the compose message UI. Let me rework the title to indicate
> that.

In the "the compose message UI"? That's different and basically impossible—there's no room. The user will see the number in the search or if they tap on the accepted recipient, but to include it "always in the compose message UI", I don't think that's a reasonable goal.

I don't understand what is wrong with just including the phone number alongside the carrier string? It satisfies everyone's use case...

Comment 27

[Jason Smith [:jsmith]]

(In reply to Rick Waldron [:rwaldron][:rick][:rick waldron] from comment #26)
> (In reply to Jason Smith [:jsmith] from comment #25)
> > we're using this bug for investigating including the phone
> > number always in the compose message UI. Let me rework the title to indicate
> > that.
> 
> In the "the compose message UI"? That's different and basically
> impossible—there's no room. The user will see the number in the search or if
> they tap on the accepted recipient, but to include it "always in the compose
> message UI", I don't think that's a reasonable goal.
> 
> I don't understand what is wrong with just including the phone number
> alongside the carrier string? It satisfies everyone's use case...

Ack. My wording wrong here. Meant to say the SMS thread view.

Comment 28

[Jason Smith [:jsmith]]

(In reply to Jason Smith [:jsmith] from comment #27)
> (In reply to Rick Waldron [:rwaldron][:rick][:rick waldron] from comment #26)
> > (In reply to Jason Smith [:jsmith] from comment #25)
> > > we're using this bug for investigating including the phone
> > > number always in the compose message UI. Let me rework the title to indicate
> > > that.
> > 
> > In the "the compose message UI"? That's different and basically
> > impossible—there's no room. The user will see the number in the search or if
> > they tap on the accepted recipient, but to include it "always in the compose
> > message UI", I don't think that's a reasonable goal.
> > 
> > I don't understand what is wrong with just including the phone number
> > alongside the carrier string? It satisfies everyone's use case...
> 
> Ack. My wording wrong here. Meant to say the SMS thread view.

And yeah, sticking the phone number alongside the carrier string sounds fine.

Comment 29

[Rick Waldron [:rwaldron]]

> Ack. My wording wrong here. Meant to say the SMS thread view.

Ok, thanks for clarifying

> And yeah, sticking the phone number alongside the carrier string sounds fine.

Great, hopefully rafaelrebolleda finds this acceptable as well.

Comment 30

[Julien Wajsberg [:julienw]]

Hey Omega,

here is an old bug that would be nice to fix. Can you try to discuss with Rafael about this?

As a summary:
* we currently don't show the phone number if that phone number has a "carrier" information associated; instead we display the carrier. This is done like this because according to user testing, south american users use this information a lot.
* as dogfooding users, we find that not showing the phone number at all is confusing, and we'd like the number to be always displayed, _in addition_ to the carrier information if it's present.

Noemi, maybe you can provide your advice or get some information from inside TEF?

Thanks to you both!

Comment 31

[Noemí Freire (:noemi)]

Hi,

As already mentioned by Rafa in comment 24 ("In our target markets, customers carry around several SIM cards to make the most out of their plans, in terms of valley/peak hours and carrier matching. Thus, knowing which carrier a user is interacting with is of vital importance in their flows in order to save money"), for our target markets, carrier info is a MUST. We are not against showing phone number at the same time but in case of any potential conflict (such as the UI one (lack of space) that was raised in the past) the carrier should be the priority.

Comment 32

[Victoria Gerchinhoren [:vicky]]

Find atteched visuals indicating how to display the necessary information in the carrier area. Both visual and visual spec.

THanks.

Comment 33

[Victoria Gerchinhoren [:vicky]]

Attachment: Visual Mockup. SMS Thread. Complete carrier and number informaiton

Comment 34

[Victoria Gerchinhoren [:vicky]]

Attachment: Visual Spec. SMS carrier info

Comment 35

[Julien Wajsberg [:julienw]]

Hey Victoria,

this is useful, thanks !

Here is an additional question for you:
* What's the spacing size between the phone number and the carrier information? (and by the way, it looks a little too close for my taste on this screenshot)

Comment 36

[Victoria Gerchinhoren [:vicky]]

(In reply to Julien Wajsberg [:julienw] from comment #35)
> Hey Victoria,
> 
> this is useful, thanks !
> 
> Here is an additional question for you:
> * What's the spacing size between the phone number and the carrier
> information? (and by the way, it looks a little too close for my taste on
> this screenshot)

Hi Julien,
The space is just a type space, I have decided to separate it with color instead of a charachter in order to make it more simple, another comma or a bar would have made it a bit cluttered. The separation space wise might seem close, but that's why the text has a different color as well, to make the separation effective.

Thanks!

Comment 37

[Julien Wajsberg [:julienw]]

I've put the mentor flag but it's not a very easy bug, because it involves changing how this line is displayed in javascript too. Especially we'll now use several elements instead of only one.

Comment 38

[Oleg Zasypkin [:azasypkin]]

Comment on attachment 8410334 [details]
Visual Spec. SMS  carrier info

Discussed with Victoria offline:

* Phone number should be displayed for all other cases too:
  ** type, number (including the case when contact doesn't have name defined);
  ** type, number carrier;

* As previously we don't display carrier header with phone number if there is no known contact behind it.

* The latest spec for carrier header is located here: https://bug950175.bugzilla.mozilla.org/attachment.cgi?id=8429571;

* If the carrier label is too long, we use ellipsis for it (...).

* The same format should be applied for all places where contact information is displayed (for details see bug 883911):
 ** Thread view header;
 ** Participant view;
 ** Remove participant confirm dialog;
 ** Contact search results;
 ** Participant context menu header.

Also it would be reasonable to fix bug 883911 in the scope of this one.

Comment 40

[Julien Wajsberg [:julienw]]

(In reply to Oleg Zasypkin [:azasypkin] from comment #38)
> Comment on attachment 8410334 [details]
> Visual Spec. SMS  carrier info
> 
> Discussed with Victoria offline:
> 
> * Phone number should be displayed for all other cases too:
>   ** type, number (including the case when contact doesn't have name
> defined);

Does that mean we'll have the number twice for unknown contacts ? Once in the title, once in the subheader ?

Comment 41

[Oleg Zasypkin [:azasypkin]]

(In reply to Julien Wajsberg [:julienw] (away until 2nd June) from comment #40)
> (In reply to Oleg Zasypkin [:azasypkin] from comment #38)
> > Comment on attachment 8410334 [details]
> > Visual Spec. SMS  carrier info
> > 
> > Discussed with Victoria offline:
> > 
> > * Phone number should be displayed for all other cases too:
> >   ** type, number (including the case when contact doesn't have name
> > defined);
> 
> Does that mean we'll have the number twice for unknown contacts ? Once in
> the title, once in the subheader ?
For unknown contacts we don't display carrier header at all, but for the known contacts without name we'll have number in both title and subheader.

Comment 42

[Oleg Zasypkin [:azasypkin]]

Attachment: GitHub pull request URL

Comment 43

[Oleg Zasypkin [:azasypkin]]

Comment on attachment 8440334 [details] [review]
GitHub pull request URL

Hey Steve, as we agreed here is the follow-up to bug 963013.

Thanks!

Comment 44

[Oleg Zasypkin [:azasypkin]]

Hey Francesco,

We're moving carrier labels used in SMS app to a single format:

"phone_type, phone_number phone_carrier" (see https://bug950175.bugzilla.mozilla.org/attachment.cgi?id=8429571 for the spec).

Current patch considers the following separators as localizable: 

* between phone_type and phone number (for en-US it's ",\u20");
* between phone_number and phone_carrier (for en-US it's "\u20").

Could you please confirm that we should make these separators localizable?

Thanks!

Comment 45

[Oleg Zasypkin [:azasypkin]]

Hey Vicky,

I'd like to confirm with you whether we still need to support the following case for carrier header (it's supported in SMS app for a long time):

"If for some reason a single contact has two phone numbers with the same type and the same carrier then only "type" and "phone number" is displayed (no carrier info is displayed)."

Is that case still valid?

Thanks!

Comment 46

[Francesco Lodolo [:flod]]

Yes, I think it's safer to have them localizable.

Comment 47

[Steve Chung [:steveck]]

Comment on attachment 8440334 [details] [review]
GitHub pull request URL

Some small comments on github but it still looks great! Please fix the conflicts before reply from visual and request review again, thanks.

Comment 48

[Victoria Gerchinhoren [:vicky]]

(In reply to Oleg Zasypkin [:azasypkin] from comment #45)
> Hey Vicky,
> 
> I'd like to confirm with you whether we still need to support the following
> case for carrier header (it's supported in SMS app for a long time):
> 
> "If for some reason a single contact has two phone numbers with the same
> type and the same carrier then only "type" and "phone number" is displayed
> (no carrier info is displayed)."
> 
> Is that case still valid?
> 
> Thanks!

Hey Oleg,
I think that if there's no constrain around it, we have no need to change it, right? Does this suppose a problem? If not, I would keep the same behavior.

Comment 49

[Oleg Zasypkin [:azasypkin]]

(In reply to Victoria Gerchinhoren [:vicky] from comment #48)
> (In reply to Oleg Zasypkin [:azasypkin] from comment #45)
> > Hey Vicky,
> > 
> > I'd like to confirm with you whether we still need to support the following
> > case for carrier header (it's supported in SMS app for a long time):
> > 
> > "If for some reason a single contact has two phone numbers with the same
> > type and the same carrier then only "type" and "phone number" is displayed
> > (no carrier info is displayed)."
> > 
> > Is that case still valid?
> > 
> > Thanks!
> 
> Hey Oleg,
> I think that if there's no constrain around it, we have no need to change
> it, right? Does this suppose a problem? If not, I would keep the same
> behavior.

Hey Vicky,

There is no problem with it, just wanted to confirm since format has changed. So will keep it.

Thanks!

Comment 50

[Oleg Zasypkin [:azasypkin]]

Comment on attachment 8440334 [details] [review]
GitHub pull request URL

(In reply to Steve Chung [:steveck] from comment #47)
> Comment on attachment 8440334 [details] [review]
> GitHub pull request URL
> 
> Some small comments on github but it still looks great! Please fix the
> conflicts before reply from visual and request review again, thanks.

Thanks for review! I've updated PR with the suggested changes.

Thanks.

Comment 51

[Steve Chung [:steveck]]

Some comments given on github. I just got some idea about the api interface, it would be good to know your thought first :)

Comment 52

[Oleg Zasypkin [:azasypkin]]

(In reply to Steve Chung [:steveck] from comment #51)
> Some comments given on github. I just got some idea about the api interface,
> it would be good to know your thought first :)

I've updated PR with the your API suggestion :) Thanks!

Comment 53

[Steve Chung [:steveck]]

Comment on attachment 8440334 [details] [review]
GitHub pull request URL

It looks great, r=me and please squash your commits before merging, thanks!

Comment 54

[Oleg Zasypkin [:azasypkin]]

(In reply to Steve Chung [:steveck] from comment #53)
> Comment on attachment 8440334 [details] [review]
> GitHub pull request URL
> 
> It looks great, r=me and please squash your commits before merging, thanks!

Thanks for review! Squashed and waiting for Travis and Try.

Comment 55

[Oleg Zasypkin [:azasypkin]]

Master: https://github.com/mozilla-b2g/gaia/commit/3aaf653afdbcc41daf565886ce4d3228264259f2

Comment 56

[Shally Li（leave from Mozilla）]

This issue has been successfully verified on Flame 2.1.
See attachment: verified_1.png and verified_2.png
Reproducing rate: 0/5

Flame 2.1 build:
Gaia-Rev        db2e84860f5a7cc334464618c6ea9e92ff82e9dd
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/211eae88f119
Build-ID        20141126001202
Version         34.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141126.033519
FW-Date         Wed Nov 26 03:35:30 EST 2014
Bootloader      L1TC00011880

Comment 57

[Shally Li（leave from Mozilla）]

Attachment: verified_1.png

Comment 58

[Shally Li（leave from Mozilla）]

Attachment: verified_2.png