Bug Tracker

Opened 11 years ago

Closed 11 years ago

#13507 closed bug (cantfix)

jQuery, CSP and Google Chrome 25

Reported by: craig@… Owned by: craig@…
Priority: undecided Milestone: None
Component: unfiled Version: 1.9.1
Keywords: Cc:
Blocked by: Blocking:


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.

Change History (8)

comment:1 Changed 11 years ago by dmethvin

Owner: set to craig@…
Status: newpending

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?

comment:2 Changed 11 years ago by craig@…

Status: pendingnew

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

comment:3 Changed 11 years ago by 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.

comment:4 Changed 11 years ago by craig@…

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

comment:5 Changed 11 years ago by Timmy Willison

Status: newpending

comment:6 Changed 11 years ago by craig@…

Status: pendingnew

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:


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

comment:7 Changed 11 years ago by 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. :)

comment:8 Changed 11 years ago by dmethvin

Resolution: cantfix
Status: newclosed

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

Note: See TracTickets for help on using tickets.