It doesn't look like anything in our code ever calls SetOwner for HTTP channels, but GetOwner is called in various places. So for now I'm going to "return NULL" for GetOwner, and DROP_DEAD for SetOwner. This will let us know (rather forcefully :) if something actually ever does call SetOwner in the child process. bz points out that it's possible that some extensions might conceivably call SetOwner on an HttpChannelChild. We can't be calling DROP_DEAD in production code, so we need to figure out if 1) it's fine to allow setting/getting the owner, but we don't need to propagate it to the chrome process; or 2) we actually need to deal with letting the chrome process know about an owner, by calling SetOwner on the chrome nsHttpChannel, and dealing with whatever happens when chrome logic calls GetOwner. Hopefully, scenario #1 is the case. Alas, bz notes that there's some code in chrome that calls GetOwner (nsScriptSecurityManager::OnChannelRedirect). So scenario #2 is possible. This is low priority, but must be investigated before we ship.

Note that if extensions call SetOwner I would fully expect them to do so in the chrome process.

So, it turns out that XHR requests call SetOwner: http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsXMLHttpRequest.cpp#1910 I haven't looked into how the code works, or how often it's called, but it gets hit from loading http://www.youtube.com/ in the testXUL demo. So it looks like there's more work to do here than we expected, and higher priority, too.

cc'ing Jonas in case he knows how/why XHR sets mOwner.

XMLHttpRequest parses (when mime type is correct) the network stream into a DOM Document. We set the owner so that the parser gives parsed documents the correct principal. I.e. it gives the parsed document the principal of the loading page.

Jonas, So does this mean that both SetOwner/GetOwner will be called only on the content process? Is there any reason the chrome channel needs to know about the Owner? It doesn't sound like it from your description.

Yes, in this case only the content process cares about the owner. Can't with certainty say that that is the case everywhere else, but I suspect so. Hmm.. actually there is one place where the chrome process cares about the owners. But that's related to the chrome:// protocol, so maybe not an issue here? (specifically, for chrome:// urls, the chrome protocol handler sets the owner to be the system principal)

http://hg.mozilla.org/projects/electrolysis/rev/2ebd848fb5ba We now support Set/get of owner, w/o propagation to chrome. This is enough to get XHR working in xpcshell tests. Thanks to Jae-Seong for the patch (bug 558801 attachment 440136 [details] [diff] [review]).