User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0 Build ID: 20161213204721 Steps to reproduce: I started building a website with a restrictive csp and whitelist as needed during development. During that I noticed editing the style of an element inside the inspector tab (element { }) is affected by csp and blocked as unsafe-inline unless this is allowed inside the policy. Actual results: Editing an elements css rules inside the inspector triggers a csp violation. Editing the existing stylesheet inside the Style Editor doesn't trigger a violation. Expected results: Editing an elements css inside the devtools should not be affected by csp.

Sounds like dev tools needs to either apply user mods in an actual injected stylesheet, or it needs to break the CSP by adding "unsafe-inline" to the page's CSP. The former is going to be easier because we don't have a way to modify an existing CSP on a page (although add-ons wants one), and weaking the CSP of a page under edit might lead to security issues (unlikely in this case).

I'm not sure if devtools have a way around that, but csp blocks stylesheets (<style>) injected from javascript as well. ``` require('http').createServer((req, res) => { res.setHeader('Content-Security-Policy', "default-src 'none'; style-src 'self'; script-src 'self' 'unsafe-inline';"); res.end('<meta charset="utf-8"><script>document.write("<style>body{background-color:red;}</style>");</script>\n'); }).listen(8888); ``` Adding `unsafe-inline` would probably trigger xss styles that have been blocked before.

The sounds very similar to bug 1185351. :ckerschb, maybe this is another one you could help with, or point DevTools in the right direction at least?

(In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #3) > The sounds very similar to bug 1185351. :ckerschb, maybe this is another > one you could help with, or point DevTools in the right direction at least? Actually, I don't know that much about the CSS specific issues here. Ehsan, you fixed Bug 1185351. Is this bug something you could help with? Potentially do we forget to check for IsInNativeAnonymousSubtree somewhere along those lines?

Bug 1185351 was different in that it was about the native anonymous content that we use to implement the Inspector UI. But in this bug, as far as I can tell, we are talking about any arbitrary element in the page, so there is no easy escape hatch -- we do need to be able to differentiate between style attributes set by devtools versus other call sites and basically avoid calling nsStyleUtil::CSPAllowsInlineStyle() if the style attribute is coming from the browser. Adding an API for devtools to be able to set the style attributes like this is pretty easy, I can help with that part. But I have no idea where in the devtools code such style attributes are set, and all of those places need to change, so I'm probably not the right person to fix the entire bug. I'd be happy to help out a devtools engineer with the Gecko side of things though.

:pbro, is there someone from DevTools side that could work with Ehsan on this?

Thank you Ehsan for proposing to help with this. There aren't a lot of inspector people available right now to work on this though. Let's ping :zer0 and see if he can help. Matteo, we've had these CSP problems for a while now, and it'd be really great to finally get rid of them as they make the inspector basically useless.

I should note that Chrome's behavior is to ignore CSP when making CSS edits like this. It took me quite a while today to figure out why my CSS changes weren't working, because I wasn't looking at the console log when making these changes. The only sign that things were wrong was that my inline styles were gone when I went back to look at an element.

Somewhat related: I noticed that, with active CSP preventing in-line styles, you *can* modify existing style sheets using `document.styleSheets[0].insertRule`. That way, you can add new rules to the document. However, all rules defined that way will then appear as `display: none !important` in the dev tools even though they have the proper effect.

Is this a duplicate of bug 1391994? It sounds similar, at least...

Yes it is. Sorry for not noticing earlier. I'm closing this one as the other one is receiving some fixes from Brad.