How is the test failing?

Note that removing step 1.2.2 *is* web visible, since the new window will have an opener unlike before.  However, if the test is failing not because of that but because of the process assignment, that seems unexpected.

The test is also failing if I don't change the test, but only remove the gmail |is_fork| logic in RenderFrameImpl::DecidePolicyForNavigation.  I assume that the |is_fork| logic should not be web-visible.

And to directly answer the question of how the test is failing:

FAIL cannot send wasm module to remote iframe assert_equals: expected (string) "didn't make it" but got (object) object "[object WebAssembly.Module]"

Sounds like an issue where WASM modules can't be sent across processes?  Strange that the test would be asserting that it doesn't work.  There was never a guarantee that the Gmail fork heuristic would end up in a different process (e.g., if we're over the process limit and end up sharing the same process), so I agree that this seems like a bug on the WASM side to expect that.

Thomas, can you help us find someone familiar with this?  Not sure whether this module sending behavior should be supported cross-process (contrary to the test expectation, but more consistent to web pages) or if the test should be flexible enough to support either outcome.

Looks like mtrofin@ might have worked on this.  Any thoughts on comment 4?

mtrofin@ isn't working on V8 anymore; I believe mstarzinger@ has picked up sharing modules across isolates.

This is intentional, see commit message: https://codereview.chromium.org/2847063002

I remember it was security-related. domenic@ may also have context on the motivation behind this particular behavior in Chrome.

Wasm modules cannot be sent across "agent cluster boundaries", which correspond to "theoretical" process boundaries from spec-land. https://html.spec.whatwg.org/multipage/webappapis.html#integration-with-the-javascript-agent-formalism

The key then is figuring out whether MAIN FRAME and POPUP FRAME are in the same agent cluster:

- If they are, then they need to be able to share memory. So Chrome needs to keep them in the same process.
- If they are not, then they can safely be in different processes, because they cannot per-spec share memory.

So the answer should not depend on Chrome's process allocation; it depends on the agent cluster concept alone.

My reading of https://html.spec.whatwg.org/multipage/webappapis.html#integration-with-the-javascript-agent-formalism , which leads us to https://html.spec.whatwg.org/multipage/browsers.html#groupings-of-browsing-contexts , is that in the example given, they are cross-origin (https://127.0.0.1:8443/ vs. https://example.test:8443/) so not in a unit of related similar-origin browsing contexts, and so not in the same agent cluster, so it should not be possible to postMessage, ever.

However, note that if you ran the test as a web platform test, then you'd probably run it on http://web-platform.test:8000/, and remote_loc would end up being on https://web-platform.test:8443. These are cross-origin, but "similar" origin-domain; i.e. if both pages did `document.domain = "web-platform.test"`, they could synchronously access each other. So in that case, they should always be able to postMessage to each other.

+binji@ who I think implemented agent cluster checks

FWIW, I see that this test was also marked as flakily timing out in issue 765738.
I plan to disable this test (since it seems it is testing/enforcing a buggy/incorrect behavior of product code) when proceeding with  issue 892375 .

Correction: my section beginning "However, note that if you ran the test as a web platform test..." draws the wrong conclusion. http: and https: sites cannot access each other even with document.domain. Please ignore that paragraph, as it was a tangent anyway.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0962f52f2b0d1627ee5b9446ec9ce79e275c428d

commit 0962f52f2b0d1627ee5b9446ec9ce79e275c428d
Author: Lukasz Anforowicz <lukasza@chromium.org>
Date: Wed Oct 17 17:56:54 2018

Remove non-standard process fork heuristic used by desktop Gmail.

Setting a new window's opener to null and navigating it cross-site used
to be a hint to Chrome that it was safe to open the link in a new
process.  Now that Site Isolation is enabled by default on desktop,
cross-site links will always open in a new process, making this
unnecessary there.

For cases where Site Isolation is not enabled, it is better to use
target=_blank rel=noreferrer (or rel=noopener) than this old,
non-standard heuristic.  See:
https://blog.chromium.org/2009/12/links-that-open-in-new-processes.html

Bug: 892212,  892375 ,  884383 
Change-Id: I50422cb6bd97f8e0f1d4ef082551ecb355ae104b
Reviewed-on: https://chromium-review.googlesource.com/c/1262089
Reviewed-by: James MacLean <wjmaclean@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Commit-Queue: Łukasz Anforowicz <lukasza@chromium.org>
Cr-Commit-Position: refs/heads/master@{#600469}
[modify] https://crrev.com/0962f52f2b0d1627ee5b9446ec9ce79e275c428d/content/renderer/render_frame_impl.cc
[delete] https://crrev.com/382ffc533cb64b0946adfbc617858a6203207d03/content/test/data/fork-popup.html
[modify] https://crrev.com/0962f52f2b0d1627ee5b9446ec9ce79e275c428d/extensions/browser/guest_view/web_view/web_view_guest.cc
[modify] https://crrev.com/0962f52f2b0d1627ee5b9446ec9ce79e275c428d/extensions/browser/guest_view/web_view/web_view_guest.h
[modify] https://crrev.com/0962f52f2b0d1627ee5b9446ec9ce79e275c428d/third_party/WebKit/LayoutTests/TestExpectations

mstarzinger@, could you PTAL?  Are you the right owner for this bug?

FWIW, the CL in #c11 simply disables the test - for the long-term we need to ensure that 1) the test is fixed to test the right behavior and 2) the product most likely also needs to be fixed to implement the right behavior.

Assigning binji@, since I think he's inherited the access checks for postMessage()'ing WASM modules.