The message manager currently makes some assumptions in both the API and implementation about having a single content process. Since this is changing, we need to design and implement the correct API for multiple content processes.
OS: Mac OS X → All
Hardware: x86 → All
Created attachment 544361 [details] [diff] [review] patch This is pretty simple. The current process mm becomes global process message manager (gpmm), and whenever a new ContentParent is created, it gets a new message manager which is added as a child to the global pmm. The patch adds also nsITreeItemFrameMessageManager interface, which is implemented by all the chrome message managers. That way one can iterate through the child message managers of some parent. Later we can add some process ID to the per-process message managers (ppmm) This is on top the patch for bug 666748 I haven't posted this to tryserver yet, since I don't know if the patch for bug 666748 works there.
Attachment #544361 - Flags: review?(benjamin)
Also, I need to mochitestify the tests, but I'd like to do that once it is clear that the patch for bug 666748 works reasonable well.
Attachment #544361 - Flags: review?(benjamin) → review+
That patch has review, so if you can post the mochitests for this one, I'll land that all together in the e10s tree.
Also, it's probably better to disconnect the message manager in ContentParent::ActorDestroy, not in ~ContentParent.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla9
You need to log in before you can comment on or make changes to this bug.