Bug 863515 - Electrolysis: Make content.opener work

content.opener… what the hell is this and why do we use it?

Oh, I guess we want to know if the browser was opened by way of some other browser.

I don't think I want to expose the opener to the parent process. Instead, I could expose a boolean on the <xul:browser> on whether or not it has an opener.

I think we're just doing presence checks anyway.

Ok, so I couldn't send up the opener info on Browser:Init because it's not set yet - it's done in nsWindowWatcher::ReadyOpenedDocShellItem, which happens after browser-child.js executes, it seems.

So I have to set a load listener and send up information then. I'll only do the first load.

Patch posted, try push out.

Hrm. So with my current patch, there's this little window of time where hasContentOpener might not be true. I think I need to make sure we never hit that window...

Boo. :(

So I've added a throw when in the indeterminate state, and I'll do a try build to see if we hit it.

Garrr… this isn't going to work. I'm getting the throw. :(

I've asked smaug whether or not we can somehow move assigning the opener earlier, so that we can access it at the Browser:init point in browser-child.js.

smaug says yes it can be done, but it needs to be done before we add <xul:browser> to the document, it think.

So my new plan is to expose a bool on nsITabParent that says whether a TabParent had a content opener, and set that to true in TabParent when responding to the create window message.

smaug likes it! Just need to remember to bump the uuid of the IDL next time.