Commenting out that line probably gets you through the initial feature detection but it's likely to hang up on other code later, for example effects.

It seems like we need to require that jQuery be run with style-src self or a URL appropriate to where the jquery.js file originates. Is there a reason you're unable to specify that?

In my case, I had a fairly simple header:

    X-WebKit-CSP: default-src 'self'

I'd have thought that would allow style rules to be set via JavaScript... but it looks like it needs unsafe-inline:

    X-WebKit-CSP: default-src 'self'; style-src 'self' 'unsafe-inline'

It is strange that this trips on the cloneNode(true) line though, rather than line above.

    div.style.backgroundClip = "content-box";
    div.cloneNode( true ).style.backgroundClip = "";
    support.clearCloneStyle = div.style.backgroundClip === "content-box";

Is https://github.com/jquery/jquery/blob/dc9b009c1325e05344fa2216fac71fac3a0a0590/test/data/support/csp.php not testing this correctly? I do see the CSP violations, but also the test passes on BrowserStack Chrome 25.

Can check later... but I believe the simple check it uses will still pass:

    jQuery(function() {
            parent.iframeCallback( jQuery.support );
    });

As the CSP violation just stops the property from being set, but the code will continue to run anyway... as in, it runs fine (possibly getting that test result wrong), and throws the error in the console (and via the reporting url, if set).

This is still a problem, and can be isolated by setting the header:

X-WebKit-CSP: default-src 'self'

And then running the following:

div1 = document.createElement('div');

div1.style.background = 'red';

var div2 = div1.cloneNode(true);

This has also been reported to Chromium:

https://code.google.com/p/chromium/issues/detail?id=189184

However a more immediate solution may be required for jQuery... of which commenting out the div.cloneNode line seems to work (although presumably it breaks the test).

It seems to me that this is definitely a bug in Chrome, because cloning an existing element should not trigger the CSP issue. And yes, we can't just comment out the line, it is there for a reason. This is good info though, and since you've reported the bug we can track it from here.

The remaining question is whether our unit test is working properly. If the test worked it seems like we'd need to remove it. :)

That particular support test isn't affected by the blocked access anyway so other than a harmless (erroneous) CSP warning we're good.