jQuery, CSP and Google Chrome 25

[[email protected]…]

I believe this is continuing on from bug #11249... but now effecting Google Chrome 25.

If CSP is enabled, you immediately get the error:

Refused to apply inline style because it violates the following Content Security Policy directive: "default-src 'self'". Note that 'style-src' was not explicitly set, so 'default-src' is used as a fallback.

This happens with:

div.cloneNode( true ).style.backgroundClip = "";

Commenting out this line does fix it, but presumably effects the test for #8908.

[dmethvin]

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?

[[email protected]…]

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";

[gibson042]

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.

[[email protected]…]

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).

[[email protected]…]

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).

[dmethvin]

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. :)

[dmethvin]

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