User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/534.50 (KHTML, like Gecko) Version/5.1 Safari/534.50 Steps to reproduce: In B2G A Telephony Call object is not clonable nor transferable. That means that I cannot pass (through postMessage) a Call object from the Home Web App to the Dialer App. Actual results: Exception Call objects are not clonable nor transferable.

(In reply to Jose M. Cantera from comment #0) > In B2G A Telephony Call object is not clonable nor transferable. That means > that I cannot pass (through postMessage) a Call object from the Home Web App > to the Dialer App. I'm not sure what you expect the right behaviour is. Can you clarify? postMessage will always transfer a JSON representation of the object. It does not clone or transfer the object itself. Certainly Call objects should be JSON-stringify-able, so this should just work. But I'm not ruling out that the current implementation has any bugs. In any case, I'm curious why you would want to transfer the call objects from one app to another. First off, with bug 674726 (which will land in m-c real soon now), only one web app ever will be able to access to navigator.mozTelephony. And even if that wasn't the case, all you really need to know is that there is an incoming call, right? And then just dispatch to the Dialer app which can then look at navigator.mozTelephony.liveCalls (or whatever it will be called...)

The use case is the following. Web App 1, typically home screen, listens to incoming call events but that app is not capable of dealing with the Call, thus once the Call arrives invokes postMessage to the Dialer app transferring the Call object. dialer.postMessage({type: incoming},'*',[theCall]) navigator.mozTelephony.liveCalls will not work because there can be other liveCalls when I'm receiving an incoming call.

Shouldn't that be handled with WebIntents/WebActivity?

(In reply to Jose M. Cantera from comment #2) > The use case is the following. Web App 1, typically home screen, listens to > incoming call events but that app is not capable of dealing with the Call, > thus once the Call arrives invokes postMessage to the Dialer app > transferring the Call object. I'm not convinced you will need the transfer. The Dialer app just needs to be notified that something is happening. It can fetch the Call object from its own navigator.mozTelephony.activeCalls or whatever it's called. Only one of those Call objects would have the "incoming" state, so it should be unambiguous. In any case, as I pointed out in comment 1, with bug 674726 landed, you will no longer be able to access navigator.mozTelephony from more than one app. So the notification will have to be in reverse: the dialer app will listen to "incoming" events and notify the home screen that there's an incoming call. This will indeed eventually happen via WebIntents, as Mounir points out. > dialer.postMessage({type: incoming},'*',[theCall]) The last parameter is not part of the API standard for postMessage! It is only supported in the Canary builds of Chrome/Chromium, I think. Definitely not something available in Gecko. Tentatively resolving this as WONTFIX since bug 674726 is making your setup impossible (no two apps can access navigatot.mozTelephony) and we don't support Chromium's postMessage API addition (and it's questionable if we ever will in this form).