I'm having trouble connecting to an app of the same origin to send a message. Will try to upload a simple test case soon.

I'm just curious, why would you want to do that? Can't you use XHR instead, for example?

(In reply to Fernando Jiménez Moreno [:ferjm] (use needinfo instead of CC, please) from comment #1) > I'm just curious, why would you want to do that? Can't you use XHR instead, > for example? We are actually trying to communicate with a pre-existing frame for an app. It's kind of a weird use-case, but here is what we are currently doing: System App - app://origin/index.html - app://origin/page2.html app://origin/index.html is already opened in the system app, and has lots of resources loaded within it. page2.html loads after the fact, and wants to setup a communication channel with the first page. They need to communicate both ways, through a messaging channel.

Why don't you just use postMessage ?

MessageChannel seems a better fit for your needs than IAC. IAC is meant to be a communication mechanism between different (certified only so far) apps. If I am not wrong, MessageChannel is currently preffed off, but maybe we can enable it for certified apps. Don't know if that's possible though. Adding some folks that might know in CC.

I think you should be able to use postMessage. MessageChannel is not yet enabled.

Our plan is to currently copy one app's code into the other, hence the reason for the same origin. We are planning on having a pref though which will allow us to specify another origin/path for the second app. I would hope that the IAC API would be flexible enough for this, but if it's not I suppose we can fallback to postMessage in the same-origin case. This does mean a bit of extra code though on the gaia side of things.

Here's an example that demonstrates the issue. I could be doing something wrong with the setup though.

Yeap, there might be some potential bugs when attempting to send message from/to the same page through the IAC API. I haven't been thinking of this scenario because I supposed users should use IAC across different apps. Anyway, we'd better take care of this tricky use case to make IAC API more flexible enough.

(In reply to Kevin Grandon :kgrandon from comment #0) > I'm having trouble connecting to an app of the same origin to send a message. After some off-line discussions, we think we should stop users using IAC in this way, because: 1. We have a simpler way to do messaging within the same app (i.e. postMessage or MessageChannel). Using IAC needs extra manifest settings. 2. IAC will do IPCs among the content processes and the central process. Using IAC to send message from/to the same app could be inefficient, because we don't have to deliver messages through the central process. 3. IAC needs permission and manifest's rules checks, which is not necessary when it comes to do messaging within the same app itself. So, I think we should avoid the .connect(...) returning a valid port for the app when it attempts to connect to itself. How do you guys feel?

I don't think postMessage works in our case because we have two iframes with remote=true loaded by the system app. When they are loaded this way, they do not receive postMessages from each other. We are also trying to minimize and contain code changes within the system app. I have not yet looked into MessageChannel, but if it solves our use case I can do so.

So to be clear, our use cases is that we have two apps open - each with the same origin. To me this feels like this is a valid use case.

Fabrice, do you know if postMessage is supposed to work cross processes?

(In reply to :Ehsan Akhgari (needinfo? me!) from comment #13) > Fabrice, do you know if postMessage is supposed to work cross processes? I think it doesn't currently. Bent or Jonas would know for sure.

I don't actually know :)

It *should* work from a desired-behavior point of view. But I don't know if that's something we've implemented yet. I think the only API where this comes up is for the inter-app-communication API. I don't know of any other APIs that allow cross-process postMessage. So the question is if IAC API was implemented to work cross-process. I would really have thought that it had, but I'm not sure.

Put another way, I don't see how the inter-app-communication API could be very useful if it doesn't work cross process. All apps run in different processes, so if you can't communicate across processes, you can't communicate across apps.

Inter-app-communication API's postMessage definitely works cross-process. That's what the postMessage under the context of cross-process means.

I think the original issue of this bug is: do we need to make IAC works in the same process? IMO, we should avoid doing that since IAC is designed for cross-app messaging. The attached patch is proposed to do so.

Generally speaking we should not have different behavior across process boundaries from within a process. That way we can enable web pages to do similar things as web apps. The IAC is a bit different though given how app focused it is.

FxOS/Gonk has been removed from the codebase. Mass-invalidating FxOS related Device Interface bugs to clean up the component. If I incorrectly invalidated something, please let me know.

Bulk correction of resolution of B2G bugs to INCOMPLETE.