1294017 - Implement window.opener.postMessage() support for async IPC communication when child runs in separate content process from parent

Status: RESOLVED DUPLICATE of bug 1353867

(Core :: DOM: Content Processes, defect)

Description

[Jukka Jylänki]

After bug 1277066 lands, it will come in a form with 'window.opener' not being available to child windows opened by a parent window. The emunittest harness uses window.opener.postMessage() to asynchronously communicate test results back from the test page to the harness page, so it would be an important feature to have for the harness.

Alternatively, we should figure out a replacement for the test harness communication if window.opener.postMessage() will not be available for a window that opts in to process isolation via the <meta> tag.

Comment 1

[Jukka Jylänki]

Michael, I remember we discussed this last week, but can't recall what the conclusion there was.

I presume synchronously accessing properties, e.g. "window.opener.foo" will be called to be unsupported, which makes sense, but "window.opener.postMessage()" can be seen as a special case.

Do we envision to spec out the "Large-Allocation: x" header feature to be incompatible with window.opener.postMessage(), or is that something that will come in later once there's time to implement it?

Are there other notable members/functions on window.opener that will be unavailable? (I'm thinking about this from the developer documentation aspect here)

Comment 2

[Nika Layzell [:nika] (ni? for response)]

(In reply to Jukka Jylänki from comment #1)
> Michael, I remember we discussed this last week, but can't recall what the
> conclusion there was.
> 
> I presume synchronously accessing properties, e.g. "window.opener.foo" will
> be called to be unsupported, which makes sense, but
> "window.opener.postMessage()" can be seen as a special case.
> 
> Do we envision to spec out the "Large-Allocation: x" header feature to be
> incompatible with window.opener.postMessage(), or is that something that
> will come in later once there's time to implement it?
> 
> Are there other notable members/functions on window.opener that will be
> unavailable? (I'm thinking about this from the developer documentation
> aspect here)

The Large-Allocation: X header is not "incompatible with postMessage". The header acts as a best effort attempt to move the given page as it is loading into a new process. If the opener page is cross-origin from the current page on a theoretical future implementation of gecko then it would be possible for us to implement `window.opener` with some type of cross-process window proxy.

However, we don't have the technology to do that right now, so instead what happens right now is that the page will not be loaded into a new process if it would have an opener.

The reason for not treating postMessage specially is because, in order to keep the spec and recommended surface area as small as possible, there is no special handling for `opener` in the discussion at all, simply an allowance for the Large-Allocation: X request to fail for any reason.

Comment 3

[Jens Stutte [:jstutte]]

Hi Nika, should I read your answer as "there is nothing to do here" (or have things even changed since then) ?

Comment 4

[Nika Layzell [:nika] (ni? for response)]

This was fixed as part of fission in bug 1353867