Able to reproduce this issue on windows 10, Ubuntu 14.04 and Mac 10.12.2 on latest chrome Dev #57.0.2987.13 and Canary #58.0.2997.0	
Issue is broken in M58.


Bisect Info:
===========
Good build : 58.0.2989.0,  Revision Range- 445281
Bad build  : 58.0.2990.0,  Revision Range- 445313

After executing the per-revision-bisect script, i got the following CL's between good and bad build versions
============================================
https://chromium.googlesource.com/chromium/src/+log/949b36db0565e9a81fc50cbb1584d64d6090c147..b57345e696995369c8df3c23782734167386baee


The suspecting Change Log is :
-----------
https://chromium.googlesource.com/v8/v8/+/2e3447bb665558b87f44c85750764cb62d0cb42f

From the above CL suspecting the below change
--------------------------------------
Review-Url: https://codereview.chromium.org/2644893004


mtrofin@- Could you please look into this issue, if it's related to your change?  if not could you please help us to reassign this issue to the right owner.



Thank You...

This is intentional. Change https://codereview.chromium.org/2646713002/ introduced it. This was after explicit feedback to treat, for the time being, wasm compilation as if it were eval().

Added eisinger@ who can explain the motivation.

FWIW, we are considering adding a separate tag, akin 'unsafe-eval', but specific to wasm.

Right, the spirit of disallowing eval is to make it harder to go from a string-like thing to a code-like thing. For the time being, you can use unsafe-eval to allow wasm. There are plans to allow for explicitly enabling eval but not wasm and the other way round

Having said all that -  @acmesquares, we'd love to understand your scenario and whether the current behavior is somehow blocking it; whether the proposed work around is reasonable for the time being; and whether the next steps we outlined (a wasm-specific "unsafe-eval"-like flag) made sense.

Thanks!

The behaviour is fine though it needs a proper error message. There's no way I could tell this was a CSP violation.
Not really bothered about the distinction between unsafe-wasm and unsafe-eval. I'm really just waiting for import.

Thanks for the feedback! Would this have been more descriptive/actionable:

"CompileError: WebAssembly.compile(): Wasm code generation disallowed in this context. In a browser, this may mean Content Security Policy is enabled"

I missed the last statement - what import? ("I'm really just waiting for import")

Thanks!

Is there a reason the error has to be ambiguous? Why would it throw other than in a browser and as a result of CSP violation?
It's obviously not as well written as:
"Uncaught EvalError: Refused to evaluate a string as JavaScript because 'unsafe-eval' is not an allowed source of script in the following Content Security Policy directive"
This is absolutely concrete.

The other reason I reported this as a bug, is WebAssembly.compile works OK in a SharedWorker even when eval is disallowed by CSP. Surely that's wrong?

I meant the import statement from ES6 module. Compiling raw bytes seems like a negligible use-case (much like eval today) once modules become available. And even more so with the addition of dynamic import.

We've actively been discussing how to reconcile Wasm with ES6 modules, at which point an import will make sense. Though until dynamic imports are supported (not sure what the status of those are), shoehorning all the use cases will be hard.

Ah, if it's being allowed in a SharedWorker without unsafe-eval, that's a bug!
Mircea, I've reopened, but maybe filing another issue around that makes sense?

Is eval also working in that shared worker setup?

No. Eval is blocked

Thanks - I'll look into it.

Could you send me a repro of the shared worker setup? Thanks!

acmesquares@: Could you please respond to C#13.

I just spent 20 minutes to solve the captcha. Do not expect any further replies.

#16 - sorry for the CAPTCHA trouble, is it broken or does it just make no sense?
Please, check the URL of the page when you experience CAPTCHA troubles, because I saw another report today about CAPTCHA troubles, but the report also had a full issue URL and instead of a bugs.chromium.org URL, it was a monorail-prod.appspot.com URL.
So make sure you use https://bugs.chromium.org/p/chromium/issues/detail?id=686369 and not https://monorail-prod.appspot.com/p/chromium/issues/detail?id=686369 - that might be it.

@mtrofin : Gentle ping, do we have any update on this issue. 

Thanks.!

The issue is focused at the inconsistency between eval and wasm.compile discussed in comments 10&11. I am not able to construct a repro, and haven't received one from the issue reporter, and, from what I gather, we won't get one.

I'd like to keep the issue open, and reach a definitive conclusion (perhaps I can get some help with constructing a repro along the lines of what the reporter mentioned?). 

I think the priority may be lowered, but i'd let the folks on cc chime on that, too.

Mircea, Response API should allow CSP to function.
Is this a good issue to track that with?

Tracking the shared worker issue separately.