> Did this work before? N/A

Oops, yes, this is a regression. Chrome 68 works fine.

Able to reproduce the issue on Windows 10, Debian Rodete and Mac 10.13.6 with chrome Stable/Beta #69.0.3497.81 but not on Dev #70.0.3538.9, Canary #71.0.3547.0

Issue is fixed in M70

Regression Range:
=================
Good Buld : #70.0.3523.0, Revision #583083
Bad Build : #70.0.3522.0, Revision #582755

After executing per-revision bisect script in reverse, got following CL:
https://chromium.googlesource.com/chromium/src/+log/44114ee80b47c219f5354c5a1d01a5d84c1765f5..c0d5967e4471eb47aa0374f254b55c9d832ba81c

Suspect CL: 
https://chromium.googlesource.com/chromium/src/+/c0d5967e4471eb47aa0374f254b55c9d832ba81c

Since Suspect CL is related to V8 autoroll, unable to find exact culprit CL, hence CC'ing the current week V8 stability sheriff for further triage.

""Unrecognized Content-Security-Policy directive 'referrer'." can still be observed in DevTools. 

See 356f4749410c1dce for a crash report.

Nothing that stands out in the big regression range for me. Handing off to stability sheriff and bmeurer@. The latter is working on promise related stuff.

FYI, the range as detected in #3 is the range that included the fix.

I used bisect-builds to go the other direction, and the revision range is:

https://chromium.googlesource.com/v8/v8/+log/44d7d7d6..6415e8af

That's unfortunately nearly as long a list of changes as the above.

After bisecting, the original cause looks like: https://crrev.com/8a95da24150bee6b8b5d63e08f21af756bfe24c4

Looking at the list of fixes, I'm guessing that the fix is:
https://crrev.com/3e545e404525540ada1c3ce3aacaab902150324e

At first glance the latter looks like a pretty big change to try to merge back (and indeed it doesn't merge cleanly).

I bisected the fix range and indeed https://chromium.googlesource.com/v8/v8/+/3e545e404525540ada1c3ce3aacaab902150324e fixes the problem.

Assigning to ahaas@, who authored both the cause and the fix of this crash. I tried to cherry-pick the fix into V8's M69 branch but it didn't apply cleanly. Andreas, can you take a look and see if you think it'd be possible to craft a version of that patch that'd be able to fix this crash on M69?

Let's not block the next 69 RC on this and get the fix on the next 69 release afterwards.

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/cecd2ed5b7cee963a0ff5e990862b7babccadd49

commit cecd2ed5b7cee963a0ff5e990862b7babccadd49
Author: Andreas Haas <ahaas@google.com>
Date: Tue Sep 11 13:15:20 2018

[wasm] Return immediately if code generation is not allowed

There was a bug in WebAssembly.instantiate in the case where a CSP
disallows WebAssembly compilation. In this case the promise returned by
WebAssembly.instantiate was rejected immediately because of the CSP,
but then compilation was started anyways, and the promise was resolved
after compilation for a second time, which caused the crash. With this
CL we do not start compilation if CSP disallows WebAssembly compilation.

R=clemensh@chromium.org

Bug:  chromium:881978 
Change-Id: Iffdb3e02c3006eb7f86211ab197f81cf20438f0e
Reviewed-on: https://chromium-review.googlesource.com/1219706
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55788}
[modify] https://crrev.com/cecd2ed5b7cee963a0ff5e990862b7babccadd49/src/wasm/wasm-js.cc
[modify] https://crrev.com/cecd2ed5b7cee963a0ff5e990862b7babccadd49/test/mjsunit/wasm/disallow-codegen.js

This bug requires manual review: Request affecting a post-stable build
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), kariahda@(iOS), cindyb@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This also need a merge to M70, pls request a merge to M70.

hablich@ for M69/M70 merge review after canary coverage. Thank you.

About #18: tldr: A merge to M70 is not necessary but can be done for performance improvements.

A merge to M70 is not really needed, although we can do it. There is a CL in M70 which fixes this crash as a side effect. However, this CL would provide better performance: with this CL we do not start WebAssembly compilation when CSP disallows compilation. M70 at the moment would start the compilation but then just ignore the result.

How safe is this merge overall?

I think this change is as safe as it can be. It just adds a return in case of an error. The return only prevents compilation from being started, as it should. After that the function ends anyways.

Here is the diff. The other changes are only tests:

   if (!i::wasm::IsWasmCodegenAllowed(i_isolate, i_isolate->native_context())) {
     thrower.CompileError("Wasm code generation disallowed by embedder");
     compilation_resolver->OnCompilationFailed(thrower.Reify());
+    return;
   }

Your change meets the bar and is auto-approved for M70. Please go ahead and merge the CL to branch 3538 manually. Please contact milestone owner if you have questions.
Owners: benmason@(Android), kariahda@(iOS), geohsu@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Please merge latest until Friday noon CEST.

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/ae7a5f83cccdff47c32083cf1dab14909eb6c4cf

commit ae7a5f83cccdff47c32083cf1dab14909eb6c4cf
Author: Andreas Haas <ahaas@chromium.org>
Date: Fri Sep 14 08:55:07 2018

Merged: [wasm] Return immediately if code generation is not allowed

There was a bug in WebAssembly.instantiate in the case where a CSP
disallows WebAssembly compilation. In this case the promise returned by
WebAssembly.instantiate was rejected immediately because of the CSP,
but then compilation was started anyways, and the promise was resolved
after compilation for a second time, which caused the crash. With this
CL we do not start compilation if CSP disallows WebAssembly compilation.

Revision: cecd2ed5b7cee963a0ff5e990862b7babccadd49

R=clemensh@chromium.org
BUG= chromium:881978 
LOG=N
NOTRY=true
NOPRESUBMIT=true
NOTREECHECKS=true

Change-Id: Id174944361e6fbee899df7894d404f42fcb76218
Reviewed-on: https://chromium-review.googlesource.com/1225977
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/branch-heads/6.9@{#47}
Cr-Branched-From: d7b61abe7b48928aed739f02bf7695732d359e7e-refs/heads/6.9.427@{#1}
Cr-Branched-From: b7e108d6016bf6b7de3a34e6d61cb522f5193460-refs/heads/master@{#54504}
[modify] https://crrev.com/ae7a5f83cccdff47c32083cf1dab14909eb6c4cf/src/wasm/wasm-js.cc
[modify] https://crrev.com/ae7a5f83cccdff47c32083cf1dab14909eb6c4cf/test/mjsunit/wasm/disallow-codegen.js

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/3c8f07a071e2edfc847c07af7c5d99134f5a0c43

commit 3c8f07a071e2edfc847c07af7c5d99134f5a0c43
Author: Andreas Haas <ahaas@google.com>
Date: Fri Sep 14 08:56:38 2018

Merged: [wasm] Return immediately if code generation is not allowed

There was a bug in WebAssembly.instantiate in the case where a CSP
disallows WebAssembly compilation. In this case the promise returned by
WebAssembly.instantiate was rejected immediately because of the CSP,
but then compilation was started anyways, and the promise was resolved
after compilation for a second time, which caused the crash. With this
CL we do not start compilation if CSP disallows WebAssembly compilation.

R=​clemensh@chromium.org

NOTRY=true
NOPRESUBMIT=true
NOTREECHECKS=true

Bug:  chromium:881978 
Change-Id: Iffdb3e02c3006eb7f86211ab197f81cf20438f0e
Reviewed-on: https://chromium-review.googlesource.com/1219706
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#55788}(cherry picked from commit cecd2ed5b7cee963a0ff5e990862b7babccadd49)
Reviewed-on: https://chromium-review.googlesource.com/1225978
Cr-Commit-Position: refs/branch-heads/7.0@{#23}
Cr-Branched-From: 6e2adae6f7f8e891cfd01f3280482b20590427a6-refs/heads/7.0.276@{#1}
Cr-Branched-From: bc08a8624cbbea7a2d30071472bc73ad9544eadf-refs/heads/master@{#55424}
[modify] https://crrev.com/3c8f07a071e2edfc847c07af7c5d99134f5a0c43/src/wasm/wasm-js.cc
[modify] https://crrev.com/3c8f07a071e2edfc847c07af7c5d99134f5a0c43/test/mjsunit/wasm/disallow-codegen.js

The latest stable Chrome is working perfectly for me. Thanks for the quick fix Andreas!

Happy to help!