AFAIU, postMessage is handled in the following way:

1. RendererA calls postMessage from location A (and specifies which origins should be able to receive the message).

2. The message reaches RendererB which performs origin checks and potentially emits a console message about the error.  RendererB doesn't have visibility into the full URL and/or line number of location A.


Brainstorming ideas gathered so far:

1. SourceLocationToken that is opaque to RendererB, but that can be used by either RendererA or Browser or DevToolsRenderer to display location in a console.  Lifetime and ownership of the tokens is unclear at this point.  Extra IPCs needed (since the console message cannot be constructed in RendererB which cannot crack the token).

2. Report postMessage origin check failure back to RendererA.  This can use PostMessageOperationToken rather than SourceLocationToken.

3. Just pass source location to RendererB (probably no go, because it breaks the isolation model).

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

commit 9a1b65feb44e32a48ad7fb51384fa868bc864008
Author: lukasza <lukasza@chromium.org>
Date: Fri May 05 18:27:23 2017

OOPIFs: Tweaking test expectations for http/tests/inspector layout tests.

This CL tweaks test expectations for http/tests/inspector layout tests,
to account for work that went into making DevTools support OOPIFs.

These tests used to timeout but now are passing fine:
  http/tests/inspector/change-iframe-src.html
  virtual/mojo-loading/http/tests/inspector/change-iframe-src.html

These tests expected a timeout but not are failing with a text diff
(tracked by https://crbug.com/718940):
  http/tests/inspector/console-cross-origin-iframe-logging.html
  virtual/mojo-loading/http/tests/inspector/console-cross-origin-iframe-logging.html

These tests are intermittently timing out locally and on Site Isolation Win
FYI bot:
  http/tests/inspector-protocol/request-referrer-policy.html
  virtual/mojo-loading/http/tests/inspector-protocol/request-referrer-policy.html

BUG=718940,  623268 
NOTRY=true
TEST=Run 10 times all http/tests/inspector tests covered by the expectations file.

Review-Url: https://codereview.chromium.org/2855323005
Cr-Commit-Position: refs/heads/master@{#469730}

[modify] https://crrev.com/9a1b65feb44e32a48ad7fb51384fa868bc864008/third_party/WebKit/LayoutTests/FlagExpectations/site-per-process

Alexey is not the right owner here.

nasko@ points out that maybe in both 1) post message case and 2) CSP frame-src / form-target cases, we could generate and send the console message directly from the browser to the dev tools process (rather than generating the console message in a renderer process).  This might work, but please note:

1. With PlzNavigate the renderer should not be able to change the origin without the browser knowing first, so there should be no race here (i.e. if browser thinks that post message targets wrong origin, then it really does target a wrong origin [since the browser is supposed to know the origin of the target at all times]).  OTOH:

1.1. The browser is not aware of suborigins (and I see that post message checks in  LocalDOMWindow::DispatchMessageEventWithOriginCheck are suborigins-aware).

1.2. dcheng@ points out document.write (which AFAIU changes the origin of a document without the browser realizing).

And some smaller issues / notes:

2. We have to also hook it up to BlinkTestController on the browser side.  That seems doable.

3. For CSP this would mean doing part of the reporting (the console message) in the browser and part in the renderer (DOM event + report to the server declaring the CSP).  This seems doable, although slightly icky.

I think we can use cross-target stack ids for this one. We already do something similar for worker.postMessage() api.