Skip to main content

Bug Tracker

Side navigation

#13507 closed bug (cantfix)

Opened February 24, 2013 04:17PM UTC

Closed March 25, 2013 04:33PM UTC

jQuery, CSP and Google Chrome 25

Reported by: Owned by:
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.

Attachments (0)
Change History (8)

Changed February 25, 2013 02:10PM UTC by dmethvin comment:1

owner: →
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?

Changed February 25, 2013 02:52PM UTC by comment:2

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. = "content-box";
    div.cloneNode( true ).style.backgroundClip = "";
    support.clearCloneStyle = === "content-box";

Changed February 25, 2013 02:59PM UTC by gibson042 comment:3

Is not testing this correctly? I do see the CSP violations, but also the test passes on BrowserStack Chrome 25.

Changed February 25, 2013 03:06PM UTC by comment:4

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

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

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

Changed March 13, 2013 01:23AM UTC by timmywil comment:5

status: newpending

Changed March 13, 2013 12:57PM UTC by comment:6

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'); = '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).

Changed March 25, 2013 02:28PM UTC by dmethvin comment:7

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

Changed March 25, 2013 04:33PM UTC by dmethvin comment:8

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.