1075699 - Calling voicemail by long-pressing the 1 button displays an error and then calls. (Error dialog persists & must be dismissed after you hang up.)

Status: VERIFIED FIXED

(Firefox OS Graveyard :: RIL, defect)

Description

[Doug Sherk (:drs) (inactive)]

STR:
Long-press the 1 button on the keypad.

Expected:
Call placed to voicemail.

Actual:
Error message displayed, then call placed to voicemail shortly thereafter.

Frequency: fairly often. I thought I saw this on master recently, but I think I had entered numbers into the keypad before long-pressing 1. Daniel says that it repros on 2.1 consistently.

Comment 1

[Daniel Holbert [:dholbert]]

Yup, this happens 100% of the time for me, using a 2.1 build on my flame (regardless of whether I've entered numbers before the 1).

Also: when you end the call (and the "in-call" screen goes away), you're left looking at the error message. You have to dismiss it by hitting "OK" before you're returned to the dialer.

The error message says:
 Unable to make a phone call now
 -------------------------------
 Cannot make a call. If you
 are already dialing, please
 hang up first.

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: screenshot of error message (after hanging up on voicemail)

Comment 3

[Johan Lorenzo [:jlorenzo]]

NO repro on 2.0:
Gaia-Rev        9725d188a733a4aeebcfcf4c52d28e1ad8a2ba6f
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/05c6a4fed6bc
Build-ID        20141002000208
Version         32.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  27
FW-Date         Thu Sep  4 14:59:02 CST 2014
Bootloader      L1TC10011800


[Blocking Requested - why for this release]: Regression from 2.0

Comment 4

[Daniel Holbert [:dholbert]]

dbaron can reproduce this in his 2.2 build, too. (I just had lunch with him & he tried it while sitting next to me & reproduced it.)

(We're both on T-Mobile -- that might be a factor here.)

Comment 5

[Wilfred Mathanaraj [:WDM]]

Triage: Regression with impact on users experience in one of the core app functionality.

Comment 6

[Tamara Hills [:thills]]

Attachment: Logs of dial 123(TMobile VM) vs. dial 411 (USA information)

Comment 7

[Tamara Hills [:thills]]

Hi Hsin-Yi,

I did some debugging on this and found that we are getting an unidentified error back in the telephony_helper.js when we dial the T-Mobile VM number (123) from a T-Mobile SIM.  

I turned on the ril debugging and compared dialing a 3 digit # 411 (our information number here in US) to dialing 123.

I'm seeing one error 19 come back when we do a REQUEST_DIAL.  I cut out a ton of lines, but basically, the sequence goes like this:

I/Gecko   ( 8856): RIL Worker: [0] Received chrome message {"number":"123","isDialEmergency":false,"isEmergency":false,"rilMessageClientId":0,"rilMessageToken":21,"rilMessageType":"dial"}

I/Gecko   ( 8856): RIL Worker: Outgoing parcel: 0,0,0,32,10,0,0,0,21,1,0,0,3,0,0,0,49,0,50,0,51,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0

I/Gecko   ( 8856): RIL Worker: New incoming parcel of size 12

I/Gecko   ( 8856): RIL Worker: Parcel (size 12): 0,0,0,0,21,1,0,0,19,0,0,0

I/Gecko   ( 8856): RIL Worker: [0] Solicited response for request type 10, token 277, error 19

Do you happen to know what the error 19 is?  I attached the full log for both working (dialing 411) and non-working (dialing 123).

The call does seem to be established, despite throwing this error.  Not sure if there is something specific to do with TMobile's network or not.

Also, as a side note, is there a place I should look for all the parcel layout definitions?

Thanks,

-tamara

Comment 8

[Hsin-Yi Tsai (she/her) away [:hsinyi]]

(In reply to Tamara Hills [:thills] from comment #7)
> Hi Hsin-Yi,
> 
> I did some debugging on this and found that we are getting an unidentified
> error back in the telephony_helper.js when we dial the T-Mobile VM number
> (123) from a T-Mobile SIM.  
> 
> I turned on the ril debugging and compared dialing a 3 digit # 411 (our
> information number here in US) to dialing 123.
> 
> I'm seeing one error 19 come back when we do a REQUEST_DIAL.  I cut out a
> ton of lines, but basically, the sequence goes like this:
> 
> I/Gecko   ( 8856): RIL Worker: [0] Received chrome message
> {"number":"123","isDialEmergency":false,"isEmergency":false,
> "rilMessageClientId":0,"rilMessageToken":21,"rilMessageType":"dial"}
> 
> I/Gecko   ( 8856): RIL Worker: Outgoing parcel:
> 0,0,0,32,10,0,0,0,21,1,0,0,3,0,0,0,49,0,50,0,51,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
> 
> I/Gecko   ( 8856): RIL Worker: New incoming parcel of size 12
> 
> I/Gecko   ( 8856): RIL Worker: Parcel (size 12): 0,0,0,0,21,1,0,0,19,0,0,0
> 
> I/Gecko   ( 8856): RIL Worker: [0] Solicited response for request type 10,
> token 277, error 19
> 
> Do you happen to know what the error 19 is?  I attached the full log for
> both working (dialing 411) and non-working (dialing 123).
> 
> The call does seem to be established, despite throwing this error.  Not sure
> if there is something specific to do with TMobile's network or not.
> 
> Also, as a side note, is there a place I should look for all the parcel
> layout definitions?
> 

Hi Tamara,

When REQUEST_DIAL fails, we will retrieve the call fail cause [1]. Per the log you provided, the last fail cause is 246 (i.e. CALL_FAIL_DIAL_MODIFIED_TO_DIAL [2]). As we don't have this value in our mapping table [3], gaia will get "unspecified error." But note that we didn't have this value in v2.0, either [4] so this "unspecified error" doesn't look like a root cause. We probably need to compare the messages b/w v2.0 and v2.2. Can you attach v2.0 log with ril messages?

Also, according to the log, seems T-mobile has STK call control for the number 123. That's why not everyone (every carrier) hits this issue.

=== log snippet ===
I/Gecko   ( 8856): RIL Worker: Parcel (size 20): 0,0,0,0,22,1,0,0,0,0,0,0,1,0,0,0,246,0,0,0
I/Gecko   ( 8856): RIL Worker: We have at least one complete parcel.
I/Gecko   ( 8856): RIL Worker: [0] Solicited response for request type 18, token 278, error 0
I/Gecko   ( 8856): RIL Worker: [0] Handling parcel as REQUEST_LAST_CALL_FAIL_CAUSE
I/Gecko   ( 8856): RIL Worker: [0] Tamara 102: 
I/Gecko   ( 8856): -*- RadioInterface[0]: Received message from worker: {"number":"123","isDialEmergency":false,"isEmergency":false,"rilMessageClientId":0,"rilMessageToken":21,"rilMessageType":"dial","request":10,"rilRequestType":10,"rilRequestError":19,"success":false}
================


[1] http://dxr.mozilla.org/mozilla-central/source/dom/system/gonk/ril_worker.js?from=ril_worker.js&case=true#5424
[2] https://www.codeaurora.org/cgit/quic/la/platform/hardware/ril/tree/include/telephony/ril.h?h=kk_rb1.32#n457
[3] http://dxr.mozilla.org/mozilla-central/source/dom/system/gonk/ril_consts.js?from=ril_consts.js#2467
[4] https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/file/69ca61f7edf3/dom/system/gonk/ril_consts.js#l2411

> Thanks,
> 
> -tamara

Comment 9

[Tamara Hills [:thills]]

Attachment: Archive.1.zip

Hi Hsin-Yi,

Thanks for your response.  I did some more testing and realized that the error is coming in earlier versions on the flame as well.  I'm seeing the error on all versions of the flame back to 1.4, but I'm not seeing it at all on the Hamachi (I checked 1.4 and 2.2/master).

The switch is telling us to translate 123 -> 18056377243 because they are load balancing the Voicemail servers.  On the Hamachi, I see that 123 number get translated to 18056377243 in the UI, but I don't on the flame.  

I'm going to try Doug Sherk's suggestion and update one of my flames to kitkat and see if that has any impact.

I will try and catch you late tonight my time to see if we can look at this together and take some help from you if that's ok.

Thanks,

-tamara

Comment 10

[Hsin-Yi Tsai (she/her) away [:hsinyi]]

1st, I think I'd need to step back a little to confirm the observed behaviour again. Per comment 1 and comment 7, the voicemail call was correctly made and displayed on callscreen but there's a problem with weird call error message, right? If I misunderstood the issue, could anyone please attach a video for clarification?

2nd point is, this issue results from different hardware behaviour, reproducible on Flame but not on hamachi. This doesn't seem a regression but a device behaviour issue. On hamachi, modem/rild returns a successful REQUEST_DIAL even a call number is modified by STK. Later, a call with a new number is notified. However, on flame, when there's STK call control, modem/rild returns a failed REQUEST_DIAL with error "CALL_FAIL_DIAL_MODIFILED_TO_DIAL (246)". Also, the call number coming with following call state change events is still "123" (not modified). I am wondering if the modem behaviour is correct or not. May I have your input here, Michael? Thank you!

3rd, we could think about having a specific error message for "CALL_FAIL_DIAL_MODIFILED_TO_DIAL" as CAF does to avoid confusing users [1]. But not sure if this options resolves my 1st question.

[1] https://www.codeaurora.org/cgit/quic/la/platform/packages/apps/Phone/tree/src/com/android/phone/InCallScreen.java?h=jb_2.5.4#n1861


NI Michael for 2), thank you!

Comment 11

[Tamara Hills [:thills]]

Attachment: Flame video

Attaching video of the issue on flame.

Comment 12

[Tamara Hills [:thills]]

Attachment: Hamachi video (without the problem)

Attaching video of Hamachi.

Comment 13

[Hsin-Yi Tsai (she/her) away [:hsinyi]]

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #10)
> 1st, I think I'd need to step back a little to confirm the observed
> behaviour again. Per comment 1 and comment 7, the voicemail call was
> correctly made and displayed on callscreen but there's a problem with weird
> call error message, right? If I misunderstood the issue, could anyone please
> attach a video for clarification?
> 
> 2nd point is, this issue results from different hardware behaviour,
> reproducible on Flame but not on hamachi. This doesn't seem a regression but
> a device behaviour issue. On hamachi, modem/rild returns a successful
> REQUEST_DIAL even a call number is modified by STK. Later, a call with a new
> number is notified. However, on flame, when there's STK call control,
> modem/rild returns a failed REQUEST_DIAL with error
> "CALL_FAIL_DIAL_MODIFILED_TO_DIAL (246)". Also, the call number coming with
> following call state change events is still "123" (not modified). I am
> wondering if the modem behaviour is correct or not. May I have your input
> here, Michael? Thank you!
> 

Hey Michael, 

One more question about the meaning of the error code: when gecko receives CALL_FAIL_DIAL_MODIFILED_TO_DIAL error, does that mean the modified call is already made successfully, and we can expect a call state change event for the call comes? Or, the error just tells that STK redirects an original number to a modified one, and the modified call might fail? Thank you.

> 3rd, we could think about having a specific error message for
> "CALL_FAIL_DIAL_MODIFILED_TO_DIAL" as CAF does to avoid confusing users [1].
> But not sure if this options resolves my 1st question.
> 
> [1]
> https://www.codeaurora.org/cgit/quic/la/platform/packages/apps/Phone/tree/
> src/com/android/phone/InCallScreen.java?h=jb_2.5.4#n1861
> 
> 
> NI Michael for 2), thank you!

Comment 14

[Tamara Hills [:thills]]

Hi Viral,

Do you know how to get qcril onto a flame device?  I've tried full flash and that seems to install mozril. tchung suggested that you might know how to do this.

Thanks,

-tamara

Comment 15

[viral [:viralwang]]

Yes I do know the answer but, sadly, the answer is we can't build our own gecko with qcril.
The only qcril we can have is the base image v184 that partner provide and I don't think it can really help you on this bug :(

Comment 16

[Tamara Hills [:thills]]

Attachment: Gecko Patch

Hi Hsin-Yi,

I've added an errorcode for us to recognize in Gaia.  I had few questions:

1. I tried to keep the variable name inline with rest of the ones in ril_consts.js but that caused me to have to adjust the spacing.  Let me know if you want a shorter name (which doesn't quite fit with the convention) or you want me to wrap just that line, or as-is.

2. Looking for some feedback on what test suites this should be included as I didn't see the other error codes in testing, but maybe missed something.

I will have gaia portion ready shortly.

Thanks,

-tamara

Comment 17

[Tamara Hills [:thills]]

Attachment: Gaia portion for feedback

Hi Anthony,

This is not a pull request as of yet.  I wanted to get feedback on it first.  I'm having a config issue with the gaia-test getting it to start up so I haven't been able to run the tests.

I'll work on that in the morning,

thanks,
-tamara

Comment 18

[Hsin-Yi Tsai (she/her) away [:hsinyi]]

(In reply to Tamara Hills [:thills] from comment #16)
> Created attachment 8502248 [details] [diff] [review]
> Gecko Patch
> 
> Hi Hsin-Yi,
> 
> I've added an errorcode for us to recognize in Gaia.  I had few questions:
> 
> 1. I tried to keep the variable name inline with rest of the ones in
> ril_consts.js but that caused me to have to adjust the spacing.  Let me know
> if you want a shorter name (which doesn't quite fit with the convention) or
> you want me to wrap just that line, or as-is.
> 

What you have in the patch looks good to me. We can leave as what it is now. 

> 2. Looking for some feedback on what test suites this should be included as
> I didn't see the other error codes in testing, but maybe missed something.
> 

You are right. We don't have a specific test case for error codes.
I think we can have a new xpcshell unit test to cover this new error code.
In that test case, we should write a fake .sendRilRequestDial() and fake Buf.readInt32(). [1] is a good example.

[1] http://dxr.mozilla.org/mozilla-central/source/dom/system/gonk/tests/test_ril_worker_cf.js?from=test_ril_worker_cf.js&case=true#1


> I will have gaia portion ready shortly.
> 
> Thanks,
> 
> -tamara

Comment 19

[Hsin-Yi Tsai (she/her) away [:hsinyi]]

Per comment 9, this isn't a regression but a device-dependent issue.

Comment 20

[Francisco Jordano [:arcturus] [:francisco]]

Per comment 19 I'm pretty tempted to remove the 2.1 nomination, not a regression and specific to the flame. But will wait till Doug and Tamara give their opinion here.

Comment 21

[Hsin-Yi Tsai (she/her) away [:hsinyi]]

(In reply to Francisco Jordano [:arcturus] [:francisco] from comment #20)
> Per comment 19 I'm pretty tempted to remove the 2.1 nomination, not a
> regression and specific to the flame. But will wait till Doug and Tamara
> give their opinion here.

+1

Comment 22

[Hsin-Yi Tsai (she/her) away [:hsinyi]]

Comment on attachment 8502248 [details] [diff] [review]
Gecko Patch

Review of attachment 8502248 [details] [diff] [review]:
-----------------------------------------------------------------

This patch deserves r+, thanks for all the hard work, Tamara.

I'm fine to have a follow-up bug for error code tests as the tests aren't that critical IMO.

Comment 23

[Anthony Ricaud (:rik)]

Comment on attachment 8502258 [details]
Gaia portion for feedback

We should put this error at the beginning in handleError, to make it more explicit:
// We ignore this because "to explain"
if (errorName === 'ModifiedDialError') {
  console.log('ModifiedDialError');
  return;
}

Also in the test, you don't want to add ModifiedDialError to the expectedErrors array.

Other than that, this looks good.

Comment 24

[Tamara Hills [:thills]]

Attachment: Pull Request for Gaia Portion

Review for gaia portion with incorporated feedbacks.

Comment 25

[Anthony Ricaud (:rik)]

Comment on attachment 8502494 [details] [review]
Pull Request for Gaia Portion

Good to go with the small comments in the PR addressed.

Comment 26

[Doug Sherk (:drs) (inactive)]

(In reply to Francisco Jordano [:arcturus] [:francisco] from comment #20)
> Per comment 19 I'm pretty tempted to remove the 2.1 nomination, not a
> regression and specific to the flame. But will wait till Doug and Tamara
> give their opinion here.

I agree.

Comment 27

[Wesley Huang [:wesley_huang] (EPM) (NI me)]

QAWanted: Just check 2.0 with T-Mobile sim card.

Comment 28

[Hsin-Yi Tsai (she/her) away [:hsinyi]]

The NI was accidentally cancelled. Reset NI Michael for comment 10 and comment 13.

Comment 29

[Cody Roesch [:croesch]]

This bug DOES reproduce on Flame 2.0 KK using T-Mobile sim.

The user can quickly catch a glimpse of the error when trying to access voicemail.

Repro: 5/5

Environmental Variables:
Device: Flame 2.0
BuildID: 20141013043753
Gaia: 21fc294d6c9b78997142153fc32c3175b4835a89
Gecko: 93530962cca3
Version: 32.0 (2.0) 
Firmware Version: L1TC10011800
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Comment 30

[Johan Lorenzo [:jlorenzo]]

Triage: QA Wanted to check the v184 raw base image with a T-Mobile. If it does repro on it, it's a partner a problem then.

Comment 31

[Tamara Hills [:thills]]

Link to try run for gecko patch:
https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=bd09604d4a22

Comment 32

[Cody Roesch [:croesch]]

This bug does NOT reproduce on Base Flame v184 build using a T-Mobile SIM. The transition to the calling screen from the dialer is seamless.

0/5 repro rate

Comment 33

[Wesley Huang [:wesley_huang] (EPM) (NI me)]

triage: it can be reproduced on our own gecko/gaia so there must be something wrong. 
This is high impact for US users to dogfooding so let's + it.

Comment 34

[Tamara Hills [:thills]]

(In reply to Cody Roesch [:croesch] from comment #32)
> This bug does NOT reproduce on Base Flame v184 build using a T-Mobile SIM.
> The transition to the calling screen from the dialer is seamless.
> 
> 0/5 repro rate

I'm able to repro on the first try with v184 and T-Mobile.

Comment 35

[Daniel Holbert [:dholbert]]

(In reply to Cody Roesch [:croesch] from comment #32)
> The transition to the calling screen from the dialer is seamless. 0/5 repro rate

(The transition from the dialer to the call is pretty fast, and I could believe that it skips past the error message in some conditions, even when it's reproducing.  A better test: do you see the error screen *after you hang up*? [it sticks around until you dismiss it, per comment 2])

Comment 36

[Cody Roesch [:croesch]]

Hey all,
    So I went back and checked the bug on V184 base with T-Mobile sim with Flame. Holding the 1 button down to access vmail on the Dialer pad then hanging up I was not able to see this error message out of 20 attempts. 0/20.

I then decided to try the recent call log and just tap on the number and make the call. Again I was not able to get the error message to occur. 0/5 attempts.

So then I decided to use Impatient user mode and rapidly tap the recently dialed number for the VMail. I finally AM able to get this error to occur on both the dialling and the after hanging up. I had to dismiss the error as decribed in comment 35.

This is different than how I was able to just hold down the 1 key to access the VMail on the dialer pad in other builds.

Apologize that I did not see this before but I did not try aggressive mode last time.

Repro Rate: 4/10

Environmental Variables:
Device: Flame 2.0
BuildID: 20140930142714
Gaia: 1dc2e29491da234cfa461916304d77ce88b50045
Version: 32.0 (2.0)
Firmware: V184
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Comment 37

[Tamara Hills [:thills]]

Attachment: Final Gecko portion with commit message

Final gecko patch with commit message.  Updated try results:
https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=eed75814fd37

Comment 38

[Ryan VanderMeulen [:RyanVM]]

Your Try runs are for Android, not B2G. Was there a reason for that?

Comment 39

[Tamara Hills [:thills]]

Thanks Ryan.  
New try run.  Still in progress when I'm posting this.
https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=cf764c873104

Comment 40

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/b2g-inbound/rev/5e414b7abb7d

Master: https://github.com/mozilla-b2g/gaia/commit/93292c51ac424e94373dff209bbd1b8661bebede

For future reference, please note that your commit message should be summarizing what the patch is doing, not restating the problem it's solving. Thanks!
https://developer.mozilla.org/en-US/docs/Developer_Guide/Committing_Rules_and_Responsibilities#Checkin_comment

Comment 41

[Anshul]

Replied to Hsin-Yi via email.

Comment 42

[Doug Sherk (:drs) (inactive)]

Comment on attachment 8509570 [details] [diff] [review]
Final Gecko portion with commit message

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Unknown.
User impact if declined: T-Mobile users will get an error when dialing their voicemail.
Testing completed: Tamara and a couple of others from the US on T-Mobile tested this.
Risk to taking this patch (and alternatives if risky): Low. It just suppresses an error.
String or UUID changes made by this patch: None.

Comment 43

[Doug Sherk (:drs) (inactive)]

Comment on attachment 8502494 [details] [review]
Pull Request for Gaia Portion

See comment 42.

Comment 44

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/5e414b7abb7d

Comment 45

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/740e80768866

The Gaia patch is going to need rebasing for v2.1 uplift.

Comment 46

[Tamara Hills [:thills]]

Attachment: New PR with rebased changes to fit into 2.1

Hi Doug,

I'm guessing we need a re-review since the code is now in different files.

This is the Gaia portion put into telephony_helper.js instead of telephony_messages.js (as telephony_messages.js refactor is not in 2.1).

Note that I don't believe the Gecko portion is in the nightly build just yet, so I've not tested end to end with the nightly that has the gecko portion.  I'll make sure to test that when I get the next nightly build.

I'll leave the NI on myself until that is done.

Thanks,

-tamara

Comment 47

[Doug Sherk (:drs) (inactive)]

Comment on attachment 8512149 [details] [review]
New PR with rebased changes to fit into 2.1

Generally, uplifts don't require review unless the patches are wildly different between branches. In this case, the code is identical, but in different files.

I would like to note that I think the summary on the PR could be better. While this fixes an issue for T-Mobile users, it could definitely impact others as well. We just haven't found any yet. It's also unspecific about what is being suppressed.

Comment 48

[Tamara Hills [:thills]]

Hi Ryan,

https://github.com/mozilla-b2g/gaia/pull/25552/ is the PR for the branch patch.

I updated the commit message with more detail on what's being suppressed as per Doug's comment.  

I have tested with the nightly 2.1 build with the gecko patch.

Is it ok for me to land this or do i need to have a sherriff do it for me?

Thanks,

-tamara

Comment 49

[Ryan VanderMeulen [:RyanVM]]

As discussed on IRC, you can land it yourself whenever. Just remember to set the v2.1 status flag appropriately when you do.

Comment 50

[Tamara Hills [:thills]]

landed for 2.1. https://github.com/mozilla-b2g/gaia/pull/25552 and set b2g 2.1 status to fixed.

Comment 51

[Tamara Hills [:thills]]

Adding merge commit:  https://github.com/mozilla-b2g/gaia/commit/a22d53b94affd351bb6403a3f024977ca656c605

Comment 52

[Duane Dixon [:ddixon]]

Issue is verified fixed in Flame 2.1, 2.2 (Full Flash, nightly, 319 MB memory). 

Actual Results: Error screen does not trigger when user dials their voicemail by long-pressing "1" in Dialer app. 

Device: Flame 2.1
BuildID: 20141029001202
Gaia: eb0aab0f13c78c7ac378ad860e865c4b6eaf669f
Gecko: 318019f80a8e
Gonk: 48835395daa6a49b281db62c50805bd6ca24077e
Version: 34.0 (2.1)
Firmware: V188
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Device: Flame 2.2
BuildID: 20141029040208
Gaia: 35e87ac4324f0f3abd93dcc70d61c9f37256a0f5
Gecko: 7e3c85754d32
Gonk: 48835395daa6a49b281db62c50805bd6ca24077e
Version: 36.0a1 (2.2)
Firmware: V188
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0