Created attachment 459268 [details] [diff] [review] Patch v.1 Self explanatory. I'm kind of tempted to want |Services.mm| to just return the appropriate thing for the context it's called from (since, afaik, the chrome process will never want a nsIContentFrameMessageManager, and viceversa for the content process). But I suppose that's a little too magical, and I could see people getting confused by |Services.mm.foo()| working in one place but not another. We can always switch in the (near) future, since the change from mmChrome/mmContent to mm is just a mechanic code change...
Given that the same service seems to implement both interfaces, is there any reason not to make this a single property QIed to both (as we do for e.g. the prefservice)? Does the QI fail depending on the context or something?
I didn't try, the concern in comment 0 (re "Services.mm.foo()") struck me first. Smaug, any opinion here? I'm increasingly tempted to just make Services.mm work for both content/chrome.
QIing depends on whether the message manager is chrome message manager or content message manager. http://bonsai-hg.konigsberg.mozilla.org/bonsai/cvsblame.cgi?file=/content/base/src/nsFrameMessageManager.cpp&rev=c6673716fd47&tree=mozilla-central&mark=77-78#69 I'm not familiar with Services.jsm, but I assume it is a helper for js to get some services. I don't understand how mmContent would work, though. There is no global message manager in content process.
Or you can create the global message manager in content process, but it wouldn't have any child message managers, so sending messages would be no-op.
(clearing assignment of bugs I'm no long planning to work on)
Assignee: dolske → nobody
You don't need a property on Services for that; you can obtain the exact same one yourself by using getService("@mozilla.org/globalmessagemanager;1") and QIing to either nsIChromeFrameMessageManager or nsIContentFrameMessageManager as necessary.
er, Cc["@mozilla.org/globalmessagemanager;1"].getService(Ci.nsIChromeFrameMessageManager), that is. I don't write privileged JS often enough, obviously.
Ah, Stack Overflow finally comes to the rescue. I think my original point stands, though. There's so many different kinds of message manager objects (parent, child, global, system, mobile) it's really hard to know what to use when. If there was some sort of helper that abstracted away the logical actions (send an X, listen for a Y, etc.) I would have had a significantly easier time of this.
Fixed by bug 1068087, I believe.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WORKSFORME
No, I'm concerned about the entire constellation of communication scopes. Chrome child to chrome parent. Same when one side is a frame script, same when one side is in a JSM, same when one side is a JS component, same for all combinations. All of those again for parent to child. I actually don't care about content at all. Just the difficulty I had in making my extensions not break under e10s separation.
(In reply to Anthony Lieuallen from comment #12) > No, I'm concerned about the entire constellation of communication scopes. > Chrome child to chrome parent. Services.cpmm is the child process message manager, so that should work to send messages to the parent process, and listen for messages from the parent process. In the parent, you could use Services.ppmm to do the same, AIUI. It doesn't matter whether you call those from frame scripts or JSMs or components - as long as you're in the right process, they will work. Also note that as of bug 1133594 you can now load a script once into the child process rather than just loading the same frame script for every process tab.
> Services.cpmm is the child process message manager, so that should work to send messages to the parent process, and listen for messages from the parent process. In the parent, you could use Services.ppmm to do the same, AIUI. Is this in the docs?
(In reply to Anthony Lieuallen from comment #14) > > Services.cpmm is the child process message manager, so that should work to send messages to the parent process, and listen for messages from the parent process. In the parent, you could use Services.ppmm to do the same, AIUI. > > Is this in the docs? https://developer.mozilla.org/en-US/Firefox/Multiprocess_Firefox/The_message_manager#Process_Message_Managers implies this, yes, though IMO we could do with improvements. Certainly the per-process (rather than per-frame) script loading that I mentioned didn't seem to be documented last I checked. The problem is there are a lot of scenarios to cover. I wonder if someone (Mike?) has ideas about how to improve docs to be easier to follow here, and/or what e10s efforts there are for this.
I think wbamberg might be the one to ask about this - he's been leading the charge on our multi-process documentation. He might have some ideas on how to make this clearer.
Flags: needinfo?(mconley) → needinfo?(wbamberg)
(let's take the documentation worries to bug 962705)
You need to log in before you can comment on or make changes to this bug.