Issue #4278 has been merged into this issue.

Is dart2js considering CSP restrictions? They are coming to the greater web, not just Chome's new package apps.

cc @kasperl.
cc @peter-ahe-google.

For now, we only use dynamic code generation to cut down on the generated code size, so it seems like we could support CSP restrictions in a few ways:

1. Just add the getters and setters to the statically generated code.
2. Try to use a different way of creating the functions.

For (2), I'm thinking of something along the lines of:

  function createGetter(field) { return function() { return this[field]; }; }
  prototype["get$" + field] = createGetter(field);

That is likely to make the getters slower (less likely to be candidates for inlining) and to use more memory (they need a context chain), but it seems like something we could measure the impact of pretty easily.

This comment was originally written by johnle...@google.com

The Closure Compiler has a optimization pass that can apply this
transformation, but it was one optimizations I disabled for DartC because
it tanked performance in the performance tests (then only running against
V8).

On Tuesday, August 7, 2012, wrote:

Added this to the Later milestone.

This came up again in an Chrome Apps hackathon.

This comment was originally written by benwells@chromium.org

It would be awesome to start experimenting with Chrom apps and Dart. If we could get some sort of workaround in place (even if it is an option in a settings file somewhere) we could start looking at getting the required extension APIs available to dart apps.

A date to shoot for would be around Oct 29th, we'll run an internal chrome apps hackathon and it would be awesome to use Dart for it.

This comment was originally written by kaisellgren@gmail.com

I don't know how much work it would be to support a flag --csp-compatible that allows you to produce CSP compatible output along with the consequences of that (output size, performance) if you really wanted to.

Set owner to @floitschG.
Added Started label.

Removed this from the Later milestone.

Added this to the M2 milestone.

Removed Priority-Medium label.
Added Priority-High label.

Fixed in r13771 by Florian.

Use flag --disallow-unsafe-eval to force dart2js to generate code that can run under CSP restrictions.

cc @sethladd.
Added Fixed label.

Thanks guys!

If the purpose of the flag is to ensure CSP compliance, it should be called --csp or something like that. --disallow-unsafe-eval sounds like it might reject a user program ('avoid' would be better than 'disallow') and raises the question of what a safe eval might be, and has no visible connection with CSP.

If there is more to CSP compliance than this change, add a flag --csp that enables --avoid-unsafe-eval and whatever else is required to get the job done.

This comment was originally written by benwells@chromium.org

This is great!

About the option name, the CSP rule that was being violated was unsafe-eval. If your CSp rule does not include 'unsafe-eval' you can't use eval or new Function (new Function was the problem I encountered). So maybe the flag is correct, but a little confusing.

The flag name was chosen to match the style of the CSP rules where you either allow or disallow certain constructs. For now, I think the option name is just fine but if we need more at some point, I'd be happy for us to take a look at specifying a bunch of CSP restrictions with just one flag.

If it would make people happier, we could also go for --csp-disallow-unsafe-eval as the option name.