Go to the settings app and see that Call Settings and Cellular & Data are disabled (SIM card not ready). It seems like bug 928294 and bug 928297 changed the behavior causing this issue in both the single SIM and dual SIM scenarios.

It seems like the following check in connectivity.js is failing causing the issue. Investigating if this is something wrong on our side. if (mobileConnections[0].radioState !== 'enabled')

I think I have found the issue. Semantics of nsIRadioInterfaceLayer radioState has changed from ready to enabled as part of bug 856553 causing this issue. This is something that I can fix in my code. Will test tomorrow with the fix and let you know.

Hsin-Yi, bug 856553 introduced a new radio state in nsIDOMMozMobileConnection which has a different semantics (enabled, enabling and so on) than the one in nsIDOMMobileConnectionInfo as part of nsRadioInterfaceLayer (off, ready and so on). This is pretty confusing; wondering why did we have these two different semantics? Also RILContentHelper uses rilContext.detailedRadioState which is actually not even defined in nsIRilContext in nsIRadioInterfaceLayer.idl.

(In reply to Anshul from comment #3) > Hsin-Yi, bug 856553 introduced a new radio state in > nsIDOMMozMobileConnection which has a different semantics (enabled, enabling > and so on) than the one in nsIDOMMobileConnectionInfo as part of > nsRadioInterfaceLayer (off, ready and so on). This is pretty confusing; > wondering why did we have these two different semantics? Thanks for the comment, and sorry for the confusing semantics. I agree that we should make them consistent. So how about we use "enabled, disabled and null" as well on nsIRadioInterfaceLayer.idl? I prefer those to ready/off because we need semantics that can represent 'transient' states. > Also > RILContentHelper uses rilContext.detailedRadioState which is actually not > even defined in nsIRilContext in nsIRadioInterfaceLayer.idl. This is our design in purpose. detailedRadioState is introduced to report 'transient' state to App. It's more like a flag or property to tell App that we are changing radio power. As a result, it's not appropriate to expose this to nsIRadioInterfaceLayer.idl because this .idl is a lower-level interface which should reflect the underlying state.

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #4) > (In reply to Anshul from comment #3) > > Hsin-Yi, bug 856553 introduced a new radio state in > > nsIDOMMozMobileConnection which has a different semantics (enabled, enabling > > and so on) than the one in nsIDOMMobileConnectionInfo as part of > > nsRadioInterfaceLayer (off, ready and so on). This is pretty confusing; > > wondering why did we have these two different semantics? > > Thanks for the comment, and sorry for the confusing semantics. > I agree that we should make them consistent. So how about we use "enabled, > disabled and null" as well on nsIRadioInterfaceLayer.idl? I prefer those to > ready/off because we need semantics that can represent 'transient' states. > > > Also > > RILContentHelper uses rilContext.detailedRadioState which is actually not > > even defined in nsIRilContext in nsIRadioInterfaceLayer.idl. > > This is our design in purpose. detailedRadioState is introduced to report > 'transient' state to App. It's more like a flag or property to tell App that > we are changing radio power. As a result, it's not appropriate to expose > this to nsIRadioInterfaceLayer.idl because this .idl is a lower-level > interface which should reflect the underlying state. And theoretically, detailedRadioState is going to be handled in MobileConnectionProvider.js once bug 843452 is done.

Hsin-Yi, yes please lets make both the radioState and detailedRadioState consistent. On this note, can we just not use detailedRadioState, why use radioState at all? Also, since detailedRadioState is not part of nsIRadioInterfaceLayer.idl, RIL:GetRilContext API is not conforming to the nsIRilContext defined in nsIRadioInterfaceLayer.idl semantically.

(In reply to Anshul from comment #6) > Hsin-Yi, yes please lets make both the radioState and detailedRadioState > consistent. On this note, can we just not use detailedRadioState, why use > radioState at all? > We need detailedRadioState exposed to WebAPI. It's our WebAPI design. Gaia relies on the details to behave correctly. > Also, since detailedRadioState is not part of nsIRadioInterfaceLayer.idl, > RIL:GetRilContext API is not conforming to the nsIRilContext defined in > nsIRadioInterfaceLayer.idl semantically. Yes, it's not that perfect right now because we are struggled with the IPC mechanism between RILContentHelper and RadioInterfaceLayer. We planned to move detailedRadioState out of RIL:GetRilContext once bug 843452 is done.

(In reply to Anshul from comment #6) > Hsin-Yi, yes please lets make both the radioState and detailedRadioState > consistent. Bug 953023 filed for this. > On this note, can we just not use detailedRadioState, why use > radioState at all? > > Also, since detailedRadioState is not part of nsIRadioInterfaceLayer.idl, > RIL:GetRilContext API is not conforming to the nsIRilContext defined in > nsIRadioInterfaceLayer.idl semantically.

Anshul, Can you please help answer Hsin here?

We can close this bug as the bug 953023 is filed to address the issue.