Closed Bug 720892 Opened 13 years ago Closed 13 years ago

WebTelephony: fix concurrent access from multiple pages

Categories

(Core :: DOM: Device Interfaces, defect)

Product:
Core
Component:
DOM: Device Interfaces
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 717451

People

(Reporter: vingtetun, Assigned: bent.mozilla)

References

Details

In Gaia, doing |navigator.mozTelephony.dial(number);| result to the "incoming" handler to be fired. In a debug build I see this assertion http://mxr.mozilla.org/mozilla-central/source/dom/telephony/Telephony.cpp#416
How old is your B2G build? This smells a lot like bug 717158! I definitely am not seeing this.
Blocks: b2g-telephony
(In reply to Philipp von Weitershausen [:philikon] from comment #1)
> How old is your B2G build? This smells a lot like bug 717158! I definitely
> am not seeing this.

I'm seeing it on desktop with m-c 85092:42368fe44c8c (pulled 2 days ago). I'm seeing that with a modified version of Gaia (see https://github.com/andreasgal/gaia/pull/299)
Please flip DEBUG = true in dom/system/b2g/RadioInterfaceLayer.js and provide a full logcat.
(In reply to Vivien Nicolas (:vingtetun) from comment #0)
> In Gaia, doing |navigator.mozTelephony.dial(number);| result to the
> "incoming" handler to be fired.

Also, I'm not sure what you mean here. This isn't a grammatically correct sentence, so it's unclear to me what exactly is happening. Please specify. (Again, logcat or GTFO :))
(In reply to Philipp von Weitershausen [:philikon] from comment #3)
> Please flip DEBUG = true in dom/system/b2g/RadioInterfaceLayer.js and
> provide a full logcat.

For info DEBUG is already set to true.

Here is what you're looking for:

-*- RadioInterfaceLayer: Requesting enumeration of calls for callback: [xpconnect wrapped nsIRILTelephonyCallback @ 0x7f09859a8b30 (native @ 0x7f098eb55d80)]
-*- RadioInterfaceLayer: Registered callback: [xpconnect wrapped nsIRILTelephonyCallback @ 0x7f09859a8b30 (native @ 0x7f098eb55d80)]
-*- RadioInterfaceLayer: Received message: {"type":"enumerateCalls","calls":[]}
-*- RadioInterfaceLayer: handleEnumerateCalls: []

WARNING: Wrong button set to NS_CONTEXTMENU event?: 'message != NS_CONTEXTMENU || button == ((context == eNormal) ? eRightButton : eLeftButton)', file ../../dist/include/nsGUIEvent.h, line 938
-*- RadioInterfaceLayer: Dialing XXXXXXXXXX
RIL Worker: Outgoing parcel: 0,0,0,48,10,0,0,0,16,0,0,0,10,0,0,0,48,0,54,0,54,0,52,0,50,0,51,0,54,0,52,0,54,0,48,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
RIL Worker: Unsolicited response for request type 11003
RIL Worker: Solicited response for request type 10, token 16
RIL Worker: Handling parcel as REQUEST_DIAL
RIL Worker: Unsolicited response for request type 1001
RIL Worker: Handling parcel as UNSOLICITED_RESPONSE_CALL_STATE_CHANGED
RIL Worker: Outgoing parcel: 0,0,0,8,9,0,0,0,17,0,0,0
RIL Worker: Solicited response for request type 9, token 17
RIL Worker: Handling parcel as REQUEST_GET_CURRENT_CALLS
RIL Worker: Outgoing parcel: 0,0,0,16,53,0,0,0,18,0,0,0,1,0,0,0,0,0,0,0
RIL Worker: Solicited response for request type 53, token 18
RIL Worker: Handling parcel as REQUEST_SET_MUTE
-*- RadioInterfaceLayer: Received message: {"type":"callStateChange","call":{"callIndex":1,"state":2,"number":"XXXXXXXXXX","name":null}}
-*- RadioInterfaceLayer: handleCallStateChange: {"callIndex":1,"state":2,"number":"XXXXXXXXXX","name":null}
-*- RadioInterfaceLayer: Using fake audio manager.
-*- RadioInterfaceLayer: No active call, put audio system into PHONE_STATE_NORMAL.
###!!! ASSERTION: Serious logic problem here!: 'aCallState == nsIRadioInterfaceLayer::CALL_STATE_INCOMING', file /home/vivien/Devel/mozilla/b2g/desktop/src/dom/telephony/Telephony.cpp, line 418
RIL Worker: Unsolicited response for request type 11017
RIL Worker: Unsolicited response for request type 11010
RIL Worker: Unsolicited response for request type 11017
RIL Worker: Unsolicited response for request type 11010
RIL Worker: Unsolicited response for request type 1001
RIL Worker: Handling parcel as UNSOLICITED_RESPONSE_CALL_STATE_CHANGED
RIL Worker: Outgoing parcel: 0,0,0,8,9,0,0,0,19,0,0,0
RIL Worker: Solicited response for request type 9, token 19
RIL Worker: Handling parcel as REQUEST_GET_CURRENT_CALLS
RIL Worker: Unsolicited response for request type 1001
RIL Worker: Handling parcel as UNSOLICITED_RESPONSE_CALL_STATE_CHANGED
RIL Worker: Outgoing parcel: 0,0,0,8,9,0,0,0,20,0,0,0
RIL Worker: Unsolicited response for request type 1029
RIL Worker: Solicited response for request type 9, token 20
RIL Worker: Handling parcel as REQUEST_GET_CURRENT_CALLS
-*- RadioInterfaceLayer: Received message: {"type":"callStateChange","call":{"callIndex":1,"state":3,"number":"XXXXXXXXXX","name":null}}
-*- RadioInterfaceLayer: handleCallStateChange: {"callIndex":1,"state":3,"number":"XXXXXXXXXX","name":null}
-*- RadioInterfaceLayer: No active call, put audio system into PHONE_STATE_NORMAL.
RIL Worker: Unsolicited response for request type 1001
RIL Worker: Handling parcel as UNSOLICITED_RESPONSE_CALL_STATE_CHANGED
RIL Worker: Outgoing parcel: 0,0,0,8,9,0,0,0,21,0,0,0
RIL Worker: Unsolicited response for request type 1029
RIL Worker: Solicited response for request type 9, token 21
RIL Worker: Handling parcel as REQUEST_GET_CURRENT_CALLS
RIL Worker: Unsolicited response for request type 1001
RIL Worker: Handling parcel as UNSOLICITED_RESPONSE_CALL_STATE_CHANGED
RIL Worker: Outgoing parcel: 0,0,0,8,9,0,0,0,22,0,0,0
RIL Worker: Solicited response for request type 9, token 22
RIL Worker: Handling parcel as REQUEST_GET_CURRENT_CALLS
-*- RadioInterfaceLayer: Received message: {"type":"callStateChange","call":{"callIndex":1,"state":0,"number":"XXXXXXXXXX","name":null}}
-*- RadioInterfaceLayer: handleCallStateChange: {"callIndex":1,"state":0,"number":"XXXXXXXXXX","name":null}
-*- RadioInterfaceLayer: Active call, put audio system into PHONE_STATE_IN_CALL.

RIL Worker: Unsolicited response for request type 1001
RIL Worker: Handling parcel as UNSOLICITED_RESPONSE_CALL_STATE_CHANGED
RIL Worker: Outgoing parcel: 0,0,0,8,9,0,0,0,23,0,0,0
RIL Worker: Solicited response for request type 9, token 23
RIL Worker: Handling parcel as REQUEST_GET_CURRENT_CALLS
-*- RadioInterfaceLayer: Received message: {"type":"callDisconnected","call":{"callIndex":1}}
RIL Worker: Outgoing parcel: 0,0,0,16,53,0,0,0,24,0,0,0,1,0,0,0,1,0,0,0
-*- RadioInterfaceLayer: handleCallDisconnected: {"callIndex":1}
-*- RadioInterfaceLayer: No active call, put audio system into PHONE_STATE_NORMAL.
RIL Worker: Solicited response for request type 53, token 24
RIL Worker: Handling parcel as REQUEST_SET_MUTE
So wait, where are you calling mozTelephony.dial() from? The dialer app? How can this access mozTelephony at the same time as the homescreen?

Somehow mozTelephony is getting an callStateChanged() update for a call object it hasn't seen yet. The current implementation isn't designed to support multiple pages at the same time, so if you hacked it to do that, then this is no surprise to me.
> So wait, where are you calling mozTelephony.dial() from? The dialer app? How
> can this access mozTelephony at the same time as the homescreen?
Because of bug 720831
> Somehow mozTelephony is getting an callStateChanged() update for a call object
> it hasn't seen yet. The current implementation isn't designed to support
> multiple pages at the same time, so if you hacked it to do that, then this is
> no surprise to me.

humm. It mean the current implementation expect the dialer to be opened to be able to receive phone calls...
Is there already a bug opened for that?
(In reply to Vivien Nicolas (:vingtetun) from comment #7)
> humm. It mean the current implementation expect the dialer to be opened to
> be able to receive phone calls...

Correct. The idea was that until we can fix that, we always load the dialer app which notifies the home screen of incoming calls via postMessage (so similar to the way you have things, except in reverse.)

> Is there already a bug opened for that?

Not that I know of. We can morph this bug into that if you like.
Morphing this bug to fix all concurrent access from multiple content pages.
Summary: ASSERTION: Serious logic problem here! in Telephony.cpp → WebTelephony: fix concurrent access from multiple pages
For https://github.com/andreasgal/gaia/pull/299 , is it OK if the homescreen unhooks from WebTelephony before launching the dialer?  Or will that still cause problems?
(In reply to Chris Jones [:cjones] [:warhammer] from comment #10)
> For https://github.com/andreasgal/gaia/pull/299 , is it OK if the homescreen
> unhooks from WebTelephony before launching the dialer?  Or will that still
> cause problems?

That won't work at all. There will still be two pages having accessed navigator.mozTelephony. There's still a good chance you're going to get into inconsistent state. And after the first phone call, the homescreen would still want to listen to incoming call events, right?

There's pretty much no way around this if we want to open navigator.mozTelephony access to multiple pages.
OK.  Let's work around this in gaia by loading the dialer on startup.
(In reply to Chris Jones [:cjones] [:warhammer] from comment #12)
> OK.  Let's work around this in gaia by loading the dialer on startup.

Sure we could do that. Or we could fix this bug, which was on our list of things to do for this week. Bent, can you tackle this soon?
Assignee: nobody → bent.mozilla
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
No longer blocks: 720831
You need to log in before you can comment on or make changes to this bug.