I use the unagi with master branch. After leaving the phone for few minutes, there's no available network for dialing and sending message. I have to reboot for getting the network connection back. Unagi Master/Central Gaia: 42c4efb7550820b7b6d6086d419a32a9e0cad174 Gecko: http://hg.mozilla.org/mozilla-central/rev/1e381c91885d BuildID 20130806104538 Version 26.0a1

I saw an error [JavaScript Error: "operator is null" {file: "jar:file:///system/b2g/omni.ja!/components/RadioInterfaceLayer.js" line: 1210}] on my device. That happened in the line |let longName = operator.longName && operator.longName.toLowerCase();| in checkRoamingBetweenOperators()[1]. [1] http://mxr.mozilla.org/mozilla-central/source/dom/system/gonk/RadioInterfaceLayer.js#1191

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #1) > Created attachment 786874 [details] > radiogonelog > > I saw an error > [JavaScript Error: "operator is null" {file: > "jar:file:///system/b2g/omni.ja!/components/RadioInterfaceLayer.js" line: > 1210}] on my device. > > That happened in the line |let longName = operator.longName && > operator.longName.toLowerCase();| in checkRoamingBetweenOperators()[1]. > > [1] > http://mxr.mozilla.org/mozilla-central/source/dom/system/gonk/ > RadioInterfaceLayer.js#1191 Also note that, when this issue occurs, we still get radio signal, and we could still receive an incoming call. We couldn't dial out because dialer forbids the operation due to null mobileConnection.voice.network. The issue occurrs when I am using a french sim card in Paris.

Observation: We have voice regState changing from NETWORK_CREG_STATE_REGISTERED_HOME to NETWORK_CREG_STATE_SEARCHING then back to NETWORK_CREG_STATE_REGISTERED_HOME without operator information changes. That leads to we clearing voiceInfo.network [1] but have no chance to update it. Seems we have too strong condition for clearing voiceInfo.network in [1]? [1] http://mxr.mozilla.org/mozilla-central/source/dom/system/gonk/RadioInterfaceLayer.js#1222

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #3) > Observation: > > We have voice regState changing from NETWORK_CREG_STATE_REGISTERED_HOME to > NETWORK_CREG_STATE_SEARCHING then back to NETWORK_CREG_STATE_REGISTERED_HOME > without operator information changes. That leads to we clearing > voiceInfo.network [1] but have no chance to update it. Seems we have too > strong condition for clearing voiceInfo.network in [1]? > > [1] > http://mxr.mozilla.org/mozilla-central/source/dom/system/gonk/ > RadioInterfaceLayer.js#1222 The registration state becomes to NETWORK_CREG_STATE_SEARCHING, does it means device is not in voice service and searching for a network? If so, I think clearing voiceInfo.network is correct behavior. And we should update voiceInfo.network after service is back (becomes to NETWORK_CREG_STATE_REGISTERED_HOME again). How do you think?

(In reply to Edgar Chen [:edgar][:echen] from comment #4) > (In reply to Hsin-Yi Tsai [:hsinyi] from comment #3) > > Observation: > > > > We have voice regState changing from NETWORK_CREG_STATE_REGISTERED_HOME to > > NETWORK_CREG_STATE_SEARCHING then back to NETWORK_CREG_STATE_REGISTERED_HOME > > without operator information changes. That leads to we clearing > > voiceInfo.network [1] but have no chance to update it. Seems we have too > > strong condition for clearing voiceInfo.network in [1]? > > > > [1] > > http://mxr.mozilla.org/mozilla-central/source/dom/system/gonk/ > > RadioInterfaceLayer.js#1222 > > The registration state becomes to NETWORK_CREG_STATE_SEARCHING, does it > means device is not in voice service and searching for a network? If so, I > think clearing voiceInfo.network is correct behavior. And we should update > voiceInfo.network after service is back (becomes to > NETWORK_CREG_STATE_REGISTERED_HOME again). How do you think? Updating when NETWORK_CREG_STATE_REGISTERED_HOME sounds a good solution to me.

Hmm..I found some interesting behavior. ================================== 08-07 13:50:51.001 I/Gecko ( 404): RIL Worker[0]: Handling parcel as UNSOLICITED_RESPONSE_VOICE_NETWORK_STATE_CHANGED 08-07 13:50:51.011 I/Gecko ( 404): RIL Worker[0]: Handling parcel as REQUEST_VOICE_REGISTRATION_STATE 08-07 13:50:51.011 I/Gecko ( 404): RIL Worker[0]: Received voiceRegistrationState network info. 08-07 13:50:51.011 I/Gecko ( 404): RIL Worker[0]: voice registration state: 2,,,0,,,,,,,,,,0, 08-07 13:50:51.021 I/Gecko ( 404): RIL Worker[0]: Handling parcel as REQUEST_OPERATOR 08-07 13:50:51.021 I/Gecko ( 404): RIL Worker[0]: Received operator network info. 08-07 13:50:51.021 I/Gecko ( 404): RIL Worker[0]: Operator: Free,,20815 ================================= ril_worker received voice registration changes to NETWORK_CREG_STATE_SEARCHING and tried to update information of operator. But the response of REQUEST_OPERATOR was "Free,,20815", actually we expect to get ",,," if device is not in service. I am not sure why. Because this information did not be cleared in searching state, so ril_worker did not send update request to RadioInterfaceLayer when service is back (Note that RadioInterfaceLayer was already clearing voice.network).

(In reply to Edgar Chen [:edgar][:echen] from comment #6) > Hmm..I found some interesting behavior. > > ================================== > 08-07 13:50:51.001 I/Gecko ( 404): RIL Worker[0]: Handling parcel as > UNSOLICITED_RESPONSE_VOICE_NETWORK_STATE_CHANGED > > 08-07 13:50:51.011 I/Gecko ( 404): RIL Worker[0]: Handling parcel as > REQUEST_VOICE_REGISTRATION_STATE > 08-07 13:50:51.011 I/Gecko ( 404): RIL Worker[0]: Received > voiceRegistrationState network info. > 08-07 13:50:51.011 I/Gecko ( 404): RIL Worker[0]: voice registration > state: 2,,,0,,,,,,,,,,0, > > 08-07 13:50:51.021 I/Gecko ( 404): RIL Worker[0]: Handling parcel as > REQUEST_OPERATOR > 08-07 13:50:51.021 I/Gecko ( 404): RIL Worker[0]: Received operator > network info. > 08-07 13:50:51.021 I/Gecko ( 404): RIL Worker[0]: Operator: Free,,20815 > ================================= > > ril_worker received voice registration changes to > NETWORK_CREG_STATE_SEARCHING and tried to update information of operator. > But the response of REQUEST_OPERATOR was "Free,,20815", actually we expect > to get ",,," if device is not in service. I am not sure why. > > Because this information did not be cleared in searching state, so > ril_worker did not send update request to RadioInterfaceLayer when service > is back (Note that RadioInterfaceLayer was already clearing voice.network). Yup, that's why I said there's no following update for voice.network. ...

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #7) > (In reply to Edgar Chen [:edgar][:echen] from comment #6) > > Hmm..I found some interesting behavior. > > > > ================================== > > 08-07 13:50:51.001 I/Gecko ( 404): RIL Worker[0]: Handling parcel as > > UNSOLICITED_RESPONSE_VOICE_NETWORK_STATE_CHANGED > > > > 08-07 13:50:51.011 I/Gecko ( 404): RIL Worker[0]: Handling parcel as > > REQUEST_VOICE_REGISTRATION_STATE > > 08-07 13:50:51.011 I/Gecko ( 404): RIL Worker[0]: Received > > voiceRegistrationState network info. > > 08-07 13:50:51.011 I/Gecko ( 404): RIL Worker[0]: voice registration > > state: 2,,,0,,,,,,,,,,0, > > > > 08-07 13:50:51.021 I/Gecko ( 404): RIL Worker[0]: Handling parcel as > > REQUEST_OPERATOR > > 08-07 13:50:51.021 I/Gecko ( 404): RIL Worker[0]: Received operator > > network info. > > 08-07 13:50:51.021 I/Gecko ( 404): RIL Worker[0]: Operator: Free,,20815 > > ================================= > > > > ril_worker received voice registration changes to > > NETWORK_CREG_STATE_SEARCHING and tried to update information of operator. > > But the response of REQUEST_OPERATOR was "Free,,20815", actually we expect > > to get ",,," if device is not in service. I am not sure why. > > > > Because this information did not be cleared in searching state, so > > ril_worker did not send update request to RadioInterfaceLayer when service > > is back (Note that RadioInterfaceLayer was already clearing voice.network). > > Yup, that's why I said there's no following update for voice.network. ... I think the fundamental problem is that we don't have consistent data in ril_worker.js and RadioInterfaceLayer.js. In the case, we clear voice.network in RadioInterfaceLayer but keep it (or still keep the operator information) in worker that leads to problems with synchronization. I guess if we address the synchronization, this issue should be fixed. How do you think?

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #8) > (In reply to Hsin-Yi Tsai [:hsinyi] from comment #7) > > (In reply to Edgar Chen [:edgar][:echen] from comment #6) > > > Hmm..I found some interesting behavior. > > > > > > ================================== > > > 08-07 13:50:51.001 I/Gecko ( 404): RIL Worker[0]: Handling parcel as > > > UNSOLICITED_RESPONSE_VOICE_NETWORK_STATE_CHANGED > > > > > > 08-07 13:50:51.011 I/Gecko ( 404): RIL Worker[0]: Handling parcel as > > > REQUEST_VOICE_REGISTRATION_STATE > > > 08-07 13:50:51.011 I/Gecko ( 404): RIL Worker[0]: Received > > > voiceRegistrationState network info. > > > 08-07 13:50:51.011 I/Gecko ( 404): RIL Worker[0]: voice registration > > > state: 2,,,0,,,,,,,,,,0, > > > > > > 08-07 13:50:51.021 I/Gecko ( 404): RIL Worker[0]: Handling parcel as > > > REQUEST_OPERATOR > > > 08-07 13:50:51.021 I/Gecko ( 404): RIL Worker[0]: Received operator > > > network info. > > > 08-07 13:50:51.021 I/Gecko ( 404): RIL Worker[0]: Operator: Free,,20815 > > > ================================= > > > > > > ril_worker received voice registration changes to > > > NETWORK_CREG_STATE_SEARCHING and tried to update information of operator. > > > But the response of REQUEST_OPERATOR was "Free,,20815", actually we expect > > > to get ",,," if device is not in service. I am not sure why. > > > > > > Because this information did not be cleared in searching state, so > > > ril_worker did not send update request to RadioInterfaceLayer when service > > > is back (Note that RadioInterfaceLayer was already clearing voice.network). > > > > Yup, that's why I said there's no following update for voice.network. ... > > I think the fundamental problem is that we don't have consistent data in > ril_worker.js and RadioInterfaceLayer.js. In the case, we clear > voice.network in RadioInterfaceLayer but keep it (or still keep the operator > information) in worker that leads to problems with synchronization. I guess > if we address the synchronization, this issue should be fixed. How do you > think? To be more clear, voice.network or data.network is assigned according to 'operatorchange' rilMessageType, but we try to clear it in 'voiceregistrationstatechange' or in 'dataregistrationstatechange.' Is this the correct way? Seems we shouldn't clear them manually in 'voiceregistrationstatechange' or in 'dataregistrationstatechange.' Instead, we let voice.network/data.network updated by 'operatorchange' as it originally being. Right?

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #9) > (In reply to Hsin-Yi Tsai [:hsinyi] from comment #8) > > I think the fundamental problem is that we don't have consistent data in > > ril_worker.js and RadioInterfaceLayer.js. In the case, we clear > > voice.network in RadioInterfaceLayer but keep it (or still keep the operator > > information) in worker that leads to problems with synchronization. I guess > > if we address the synchronization, this issue should be fixed. How do you > > think? > > To be more clear, voice.network or data.network is assigned according to > 'operatorchange' rilMessageType, but we try to clear it in > 'voiceregistrationstatechange' or in 'dataregistrationstatechange.' Is this > the correct way? Seems we shouldn't clear them manually in > 'voiceregistrationstatechange' or in 'dataregistrationstatechange.' Instead, > we let voice.network/data.network updated by 'operatorchange' as it > originally being. Right? Yes, we should have the consistent data in ril_worker.js and RadioInterfaceLayer.js. One possible solution is as you mentioned in comment #8, let {voice|data}.network updated by 'operatorchange' only. And I am thinking some other problems: 1. In this case, registration status is searching, but REQUEST_OPERATOR still replies 'Free,,20815', should we clear voice.network? If not, Gaia may get some strange result, voice is not registered, but has operator's information. 2. What value should be returned for {voice|data}.network when device is not in service. Null or nsIDOMMozMobileNetworkInfo object with all properties are null?

(In reply to Edgar Chen [:edgar][:echen] from comment #10) > (In reply to Hsin-Yi Tsai [:hsinyi] from comment #9) > > (In reply to Hsin-Yi Tsai [:hsinyi] from comment #8) > > > I think the fundamental problem is that we don't have consistent data in > > > ril_worker.js and RadioInterfaceLayer.js. In the case, we clear > > > voice.network in RadioInterfaceLayer but keep it (or still keep the operator > > > information) in worker that leads to problems with synchronization. I guess > > > if we address the synchronization, this issue should be fixed. How do you > > > think? > > > > To be more clear, voice.network or data.network is assigned according to > > 'operatorchange' rilMessageType, but we try to clear it in > > 'voiceregistrationstatechange' or in 'dataregistrationstatechange.' Is this > > the correct way? Seems we shouldn't clear them manually in > > 'voiceregistrationstatechange' or in 'dataregistrationstatechange.' Instead, > > we let voice.network/data.network updated by 'operatorchange' as it > > originally being. Right? > > Yes, we should have the consistent data in ril_worker.js and > RadioInterfaceLayer.js. One possible solution is as you mentioned in comment > #8, let {voice|data}.network updated by 'operatorchange' only. > And I am thinking some other problems: > 1. In this case, registration status is searching, but REQUEST_OPERATOR > still replies 'Free,,20815', should we clear voice.network? If not, Gaia may > get some strange result, voice is not registered, but has operator's > information. How does spec say about this kind of case? > 2. What value should be returned for {voice|data}.network when device is not > in service. Null or nsIDOMMozMobileNetworkInfo object with all properties > are null? How are we doing right now? I think we use null as default value right?

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #11) > (In reply to Edgar Chen [:edgar][:echen] from comment #10) > > > > Yes, we should have the consistent data in ril_worker.js and > > RadioInterfaceLayer.js. One possible solution is as you mentioned in comment > > #8, let {voice|data}.network updated by 'operatorchange' only. > > And I am thinking some other problems: > > 1. In this case, registration status is searching, but REQUEST_OPERATOR > > still replies 'Free,,20815', should we clear voice.network? If not, Gaia may > > get some strange result, voice is not registered, but has operator's > > information. > > How does spec say about this kind of case? I am not sure does any spec have this kind of information. Anyway, I will try to find out. > > > 2. What value should be returned for {voice|data}.network when device is not > > in service. Null or nsIDOMMozMobileNetworkInfo object with all properties > > are null? > > How are we doing right now? I think we use null as default value right? Now we returns null if device is not in service.

(In reply to Edgar Chen [:edgar][:echen] from comment #12) > (In reply to Hsin-Yi Tsai [:hsinyi] from comment #11) > > (In reply to Edgar Chen [:edgar][:echen] from comment #10) > > > > > > Yes, we should have the consistent data in ril_worker.js and > > > RadioInterfaceLayer.js. One possible solution is as you mentioned in comment > > > #8, let {voice|data}.network updated by 'operatorchange' only. > > > And I am thinking some other problems: > > > 1. In this case, registration status is searching, but REQUEST_OPERATOR > > > still replies 'Free,,20815', should we clear voice.network? If not, Gaia may > > > get some strange result, voice is not registered, but has operator's > > > information. > > > > How does spec say about this kind of case? > > I am not sure does any spec have this kind of information. > Anyway, I will try to find out. > If spec doesn't say it explicitly, then I also agree clearing voice.network in searching state as you suggested. > > > > > 2. What value should be returned for {voice|data}.network when device is not > > > in service. Null or nsIDOMMozMobileNetworkInfo object with all properties > > > are null? > > > > How are we doing right now? I think we use null as default value right? > > Now we returns null if device is not in service.

hmm.. I found some new clues, the operator information is still there maybe is because data registration status is still 'registered'. We should also handle operator information of data and voice separately. ================================== 08-07 13:50:51.011 I/Gecko ( 404): RIL Worker[0]: Handling parcel as REQUEST_VOICE_REGISTRATION_STATE 08-07 13:50:51.011 I/Gecko ( 404): RIL Worker[0]: Received voiceRegistrationState network info. 08-07 13:50:51.011 I/Gecko ( 404): RIL Worker[0]: voice registration state: 2,,,0,,,,,,,,,,0, 08-07 13:50:51.011 I/Gecko ( 404): RIL Worker[0]: Handling parcel as REQUEST_DATA_REGISTRATION_STATE 08-07 13:50:51.011 I/Gecko ( 404): RIL Worker[0]: Received dataRegistrationState network info. 08-07 13:50:51.011 I/Gecko ( 404): RIL Worker[0]: Queuing dataRegistrationState network info message: {"regState":1,"state":"registered","connected":true,"roaming":false,"emergencyCallsOnly":false,"cell":{"gsmLocationAreaCode":3754,"gsmCellId":196077768},"radioTech":3,"type":"umts","rilMessageType":"dataregistrationstatechange"} 08-07 13:50:51.021 I/Gecko ( 404): RIL Worker[0]: Handling parcel as REQUEST_OPERATOR 08-07 13:50:51.021 I/Gecko ( 404): RIL Worker[0]: Received operator network info. 08-07 13:50:51.021 I/Gecko ( 404): RIL Worker[0]: Operator: Free,,20815 =========================

Upload correct patch

(In reply to Edgar Chen [:edgar][:echen] from comment #16) > Created attachment 787426 [details] [diff] [review] > WIP, Part 1: Have a consistent operator information in ril_worker and > RadioInterfaceLayer, v1 > > Upload correct patch This WIP patch is not the final one, just a quick fix for this bug. I would like to refactor some other place as well. In this patch, I added a new variable, networkInfo, in RadioInterfaceLayer, this variable is synced with ril_worker. And {voice|data}.network will update separately. Although this patch works well with hacked emulator, I still want to make sure it fixes this bug in live network. Hsinyi, it seems it is easily to reproduce in Paris, could you help to test it? Thanks in advance.

Sure, I will get back to you later!

After applying the WIP patch, I haven't seen this issue so far. :) Will keep you updated!

Refactor the batched message.

Comment on attachment 787937 [details] [diff] [review] Patch: Have a consistent operator information in ril_worker and RadioInterfaceLayer, v3 1. Handle {voice|data}.network separately. And make sure the operator information in ril_worker and RadioInterfaceLayer are synced. 2. Remove |batch| from IPC messages.

Comment on attachment 787937 [details] [diff] [review] Patch: Have a consistent operator information in ril_worker and RadioInterfaceLayer, v3 Review of attachment 787937 [details] [diff] [review]: ----------------------------------------------------------------- ::: dom/system/gonk/RadioInterfaceLayer.js @@ +1231,2 @@ > if (newInfo.regState !== RIL.NETWORK_CREG_STATE_REGISTERED_HOME && > newInfo.regState !== RIL.NETWORK_CREG_STATE_REGISTERED_ROAMING) { Maybe we could use |newInfo.state !== RIL.GECKO_MOBILE_CONNECTION_STATE_REGISTERED| here.

(In reply to Edgar Chen [:edgar][:echen] from comment #23) > Comment on attachment 787937 [details] [diff] [review] > Patch: Have a consistent operator information in ril_worker and > RadioInterfaceLayer, v3 > > Review of attachment 787937 [details] [diff] [review]: > ----------------------------------------------------------------- > > ::: dom/system/gonk/RadioInterfaceLayer.js > @@ +1231,2 @@ > > if (newInfo.regState !== RIL.NETWORK_CREG_STATE_REGISTERED_HOME && > > newInfo.regState !== RIL.NETWORK_CREG_STATE_REGISTERED_ROAMING) { > > Maybe we could use |newInfo.state !== > RIL.GECKO_MOBILE_CONNECTION_STATE_REGISTERED| here. Yes, we could. They actually mean the exactly the same thing. But the latter seems make things clearer.

Address comment #23.

Comment on attachment 788029 [details] [diff] [review] Patch: Have a consistent operator information in ril_worker and RadioInterfaceLayer, v4 Review of attachment 788029 [details] [diff] [review]: ----------------------------------------------------------------- ::: dom/system/gonk/RadioInterfaceLayer.js @@ +748,5 @@ > dump("-*- RadioInterface[" + this.clientId + "]: " + s + "\n"); > }, > > /** > + * An utility function to copy objects. The srcInfo may contain nit: s/An utility/A utility @@ +1211,5 @@ > !(equalsMcc && (equalsLongName || equalsShortName)); > }, > > /** > + * Handle the voice connection's state has changed. nit: Handle voice connection changes. @@ +1244,5 @@ > } > }, > > + /** > + * Handle the data connection's state has changed. nit: Handle data connection changes. @@ +1386,5 @@ > destNetwork.mcc != srcNetwork.mcc; > }, > > + /** > + * Handle Operator information has changed. nit: Handle operator information changes. @@ +1406,5 @@ > message.mcc + "-" + message.mnc); > } catch (e) {} > } > > + if (!voice.network && !batch) { Would there be any chance that the registered operator jumps from this one to another one with |GECKO_MOBILE_CONNECTION_STATE_REGISTERED| unchanged? I mean, do we need to have a more careful check, i.e |voice.network != operatorInfo|, instead of simply |!voice.network|?

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #26) > Comment on attachment 788029 [details] [diff] [review] > Patch: Have a consistent operator information in ril_worker and > RadioInterfaceLayer, v4 > > Review of attachment 788029 [details] [diff] [review]: > ----------------------------------------------------------------- > > ::: dom/system/gonk/RadioInterfaceLayer.js > @@ +1406,5 @@ > > message.mcc + "-" + message.mnc); > > } catch (e) {} > > } > > > > + if (!voice.network && !batch) { > > Would there be any chance that the registered operator jumps from this one > to another one with |GECKO_MOBILE_CONNECTION_STATE_REGISTERED| unchanged? I > mean, do we need to have a more careful check, i.e |voice.network != > operatorInfo|, instead of simply |!voice.network|? When operator information changes, operatorInfo will be updated no matter registration changes or not. And voice.network is either null or operatorInfo (unregistered or registered). |!voice.network|, this check is for the case that if voice is unregistered (voice.network is null), we don't need to send RIL:VoiceInfoChanges even operator information is changed.

Comment on attachment 788029 [details] [diff] [review] Patch: Have a consistent operator information in ril_worker and RadioInterfaceLayer, v4 Review of attachment 788029 [details] [diff] [review]: ----------------------------------------------------------------- ::: dom/system/gonk/RadioInterfaceLayer.js @@ +1406,5 @@ > message.mcc + "-" + message.mnc); > } catch (e) {} > } > > + if (!voice.network && !batch) { Haha, it should be |if (voice.network && !batch)| ;-)

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #28) > Comment on attachment 788029 [details] [diff] [review] > Patch: Have a consistent operator information in ril_worker and > RadioInterfaceLayer, v4 > > Review of attachment 788029 [details] [diff] [review]: > ----------------------------------------------------------------- > > ::: dom/system/gonk/RadioInterfaceLayer.js > @@ +1406,5 @@ > > message.mcc + "-" + message.mnc); > > } catch (e) {} > > } > > > > + if (!voice.network && !batch) { > > Haha, it should be |if (voice.network && !batch)| ;-) And same for data.network below.

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #28) > Comment on attachment 788029 [details] [diff] [review] > Patch: Have a consistent operator information in ril_worker and > RadioInterfaceLayer, v4 > > Review of attachment 788029 [details] [diff] [review]: > ----------------------------------------------------------------- > > ::: dom/system/gonk/RadioInterfaceLayer.js > @@ +1406,5 @@ > > message.mcc + "-" + message.mnc); > > } catch (e) {} > > } > > > > + if (!voice.network && !batch) { > > Haha, it should be |if (voice.network && !batch)| ;-) Thanks for catching this! :)

Address review comment #26, comment #28 and comment #29.

Comment on attachment 788169 [details] [diff] [review] Patch: Have a consistent operator information in ril_worker and RadioInterfaceLayer, v5 Great! Thank you~

try server: https://tbpl.mozilla.org/?tree=Try&rev=fd307776cd49

Removing koi? since this is in gecko 26 which will be the basis for Firefox OS 1.2.