When an a CSP violation occurs from within a chrome-extension frame, it gets logged to the console, like so:

[22048:14020:0324/135309.127:INFO:CONSOLE(0)] "Refused to frame 'http://localhos
t:55803/' because it violates the following Content Security Policy directive: "
frame-src 'self' blob: filesystem: data: chrome-extension-resource:".
", source: chrome-extension://febckchdcnjnkfpnhdddkfajgoahbogk/main.html (0)

However, the corresponding 'securitypolicyviolation' event only fires if PlzNavigate is enabled (--enable-browser-side-navigation), so the event cannot be caught by the document.

The reason such CSP events don't fire is due to the following workaround code in ContentSecurityPolicy::reportViolation():

  // TODO(mkwst): Obviously, we shouldn't hit this check, as extension-loaded
  // resources should be allowed regardless. We apparently do, however, so
  // we should at least stop spamming reporting endpoints. See
  //  https://crbug.com/524356  for detail.
  if (!violationData.sourceFile().isEmpty() &&
      shouldBypassContentSecurityPolicy(
          KURL(ParsedURLString, violationData.sourceFile()))) {
    return;
  }

There are two potential issues here then:
 - In PlzNavigate, sourceFile() is currently empty (although it does appear in the console message), explaining the different event-firing behavior.
 - The workaround above was apparently intended to suppress CSP violations from content scripts that were being reported to the main document. However, it seems inappropriate to do this when the main document itself is a chrome-extension:// resource, since all extensions frames run with restrictive CSPs in place.

https://codereview.chromium.org/2775953002 refurbishes and re-enables a CSP test (PlatformAppBrowserTest.Iframes) that currently passes only in PlzNavigate.