879710 - B2G RIL: find a better solution to update data cached in RILContentHelper

Status: RESOLVED DUPLICATE of bug 843452

(Firefox OS Graveyard :: RIL, defect)

Description

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

This issue is originally reported in bug 873995, i.e. the cardState in telephony_helper.js isn't updated when user turns off airplane mode. Per more investigation, the root cause is a timing issue between MobileConnectionMsg registration and cardstate update message sent from chrome. Below is what's going on there.

1) User turn off airplane mode and redial
2) in [1], mozMobileConnection of dialer app is initiated
3) then, content (RILContentHelper of the dialer process) sends out mobileConnection registration message to chrome (RadioInterfaceLayer)
4) Note, right at this moment, RadioInterfaceLayer gets updates from modem that cardState has been changed from null to absent. It sends out update messages to the registered content process
5) RadioInterfaceLayer receives the registration message sent in 3) eventually. That's why the dialer app has no chance to be updated that should have been done in 4)

Let's find out a way to avoid this issue.

[1] https://github.com/mozilla-b2g/gaia/blob/v1.0.1/apps/communications/dialer/js/telephony_helper.js#L40

Comment 1

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

Just have a brief discussion with Aknow, I think one possible solution could be:
RadioInterfaceLayer sends out cardstate change messages to that content process which just registered once the registration is completed, even no unsolicited events are coming from modem at that moment. In this way, we guarantee the newly joining content process can be up-to-date.

Any ideas?

Comment 2

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

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #1)
> Just have a brief discussion with Aknow, I think one possible solution could
> be:
> RadioInterfaceLayer sends out cardstate change messages to that content
> process which just registered once the registration is completed, even no
> unsolicited events are coming from modem at that moment. In this way, we
> guarantee the newly joining content process can be up-to-date.
> 
> Any ideas?

But note that this issue can happen to not only cardstatechange but also other mobileconnection events. If we think the above proposal is feasible, then what kind of updating messages we should send?

Comment 3

[Szu-Yu Chen [:aknow] (inactive)]

There are two step in window.navigator.mozMobileConnection
1. MobileConnection() => do_GetService(NS_RILCONTENTHELPER_CONTRACTID); 
2. MobileConnection::Init() => mProvider->RegisterMobileConnectionMsg(mListener);

another idea:

step1... Construct RILContentHelper and register msg between RILContentHelper and RadioInterfaceLayer in the same time. That guarantees RILContentHelper won't miss any update from RadioInterfaceLayer

step2... register msg between MobileConnection and its provider RILContentHelper

drawback:
I dont't know whether it is possible to register only some kinds of msg in step1 (ex: telephony, mobileconnection, ...)
If not, we will get more msg traffic between RILContentHelper and RadioInterfaceLayer.

Comment 4

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

(In reply to Szu-Yu Chen [:aknow] from comment #3)
> There are two step in window.navigator.mozMobileConnection
> 1. MobileConnection() => do_GetService(NS_RILCONTENTHELPER_CONTRACTID); 
> 2. MobileConnection::Init() =>
> mProvider->RegisterMobileConnectionMsg(mListener);
> 
> another idea:
> 
> step1... Construct RILContentHelper and register msg between
> RILContentHelper and RadioInterfaceLayer in the same time. That guarantees
> RILContentHelper won't miss any update from RadioInterfaceLayer

That is an ideal solution, but it's unfortunately not going to work. RILContentHelper is a service that would be used for content processes granted various permissions. If a content process without mobileconnection permission sends a registration message to RadioInterfaceLayer, the process will be killed. 


> 
> step2... register msg between MobileConnection and its provider
> RILContentHelper
> 
> drawback:
> I dont't know whether it is possible to register only some kinds of msg in
> step1 (ex: telephony, mobileconnection, ...)
> If not, we will get more msg traffic between RILContentHelper and
> RadioInterfaceLayer.

Comment 5

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

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #4)
> (In reply to Szu-Yu Chen [:aknow] from comment #3)
> > There are two step in window.navigator.mozMobileConnection
> > 1. MobileConnection() => do_GetService(NS_RILCONTENTHELPER_CONTRACTID); 
> > 2. MobileConnection::Init() =>
> > mProvider->RegisterMobileConnectionMsg(mListener);
> > 
> > another idea:
> > 
> > step1... Construct RILContentHelper and register msg between
> > RILContentHelper and RadioInterfaceLayer in the same time. That guarantees
> > RILContentHelper won't miss any update from RadioInterfaceLayer
> 
> That is an ideal solution, but it's unfortunately not going to work.
> RILContentHelper is a service that would be used for content processes
> granted various permissions. If a content process without mobileconnection
> permission sends a registration message to RadioInterfaceLayer, the process
> will be killed. 
> 

More thoughts, bug 843452 is helpful in the achievement of this ideal solution. I would suggest to mark this depends on bug 843452.

> 
> > 
> > step2... register msg between MobileConnection and its provider
> > RILContentHelper
> > 
> > drawback:
> > I dont't know whether it is possible to register only some kinds of msg in
> > step1 (ex: telephony, mobileconnection, ...)
> > If not, we will get more msg traffic between RILContentHelper and
> > RadioInterfaceLayer.

Comment 6

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

This issue has been resolved in bug 843452.