Also see bug 1455663.

I asked Christoph Kerschbaumer [:ckerschb] (based in Austria) what we should do.

He said "If needed we can definitely find a fix for the specific problem reported in this bug. Overall, we are going to move the CSP from the Principal into the Client (within the loadinfo) over in Bug 965637. I am confident that the changes within Bug 965637 provide a broader solution to all the Devtools related problems with CSP we are facing."

(In reply to Patrick Brosset <:pbro> from comment #10)

As Ehsan said, we either need a way to differentiate DOM elements/attributes
added/modified by devtools so we can avoid them being subject to the site's
CSP, or find another way to inject stylesheets.

The only other way I can think of now is attaching an author stylesheet
using the sdk:
https://developer.mozilla.org/en-US/Add-ons/SDK/Low-Level_APIs/
stylesheet_style
Something like this:

let {Style} = require("sdk/stylesheet/style");
let {attach} = require("sdk/content/mod");
let style = Style({
source: "body{background:blue;}",
type: "author"
});
attach(style, win);

This works even with the site's CSP. The "author" type makes it show nicely
in the rule-view, however the new sheet doesn't appear in the style-editor
somehow. Also, the SDK Style constructor doesn't seem to return an object we
can later use to modify the sheet, so we'd have to detach and re-attach a
new sheet every time a property is modified/added/deleted.

Injecting author stylesheets through the SDK would also be blocked. User stylesheets would work but this would be very confusing to users as the specificity of user sheets is completely different from that of author stylesheets.

Beyond that we still need to be able to inject scripts e.g. for the console to work.

@ckerschb you said that "If needed we can definitely find a fix for the specific problem reported in this bug. Overall, we are going to move the CSP from the Principal into the Client (within the loadinfo) over in Bug 965637. I am confident that the changes within Bug 965637 provide a broader solution to all the Devtools related problems with CSP we are facing."
@ckerschb In Chrome the DevTools are completely immune to CSP so this is an issue keeping an increasingly large number of users using Chrome.
@ckerschb We have a bunch of issues here.
@ckerschb Can you see a way forward for us? This really needs dealing with because it is giving Chrome a huge advantage when it comes to Developer Tools.

@hkirschner Just needinfoing you so you can see comment 15.

Chrome DevTools are immune to CSP so this issue is giving them a competitive advantage.

Bug 965637 has been on my radar for a while and I was hoping that these kind of issues will quickly be addressed given the improved foundation.

CSP issues are not just affecting devtools and but also devtools extensions (bug 1267027). The impact on web compat caused by developers being enable to use the tools, can be severe. CSP-protected pages are presumably often in the productivity/finance/social/enterprise categories and critical for users to work well.

(In reply to Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe] from comment #15)

@ckerschb Can you see a way forward for us? This really needs dealing with because it is giving Chrome a huge advantage when it comes to Developer Tools.

I totally agree that we need a generic solution for the problem moving forward because having Devtools blocked by CSP really shouldn't happen. It seems Bug 1391994 is very similar to this one. Let me dig into the problem a little to get a better overview of what we can do. Keeping my ni? for now.

New STR to test this again:

• open https://crates.io/crates/goblin
• open the inspector panel in DevTools
• in the Rules panel where the CSS is displayed, click the + icon in the toolbar to try to add a new rule.

Expected: a new <style> stylesheet appears in the DOM and the new rule (pre-filled with some default selector) appears in the Rules panel ready for you to edit
Actual: the new <style> node appears, but nothing else happens. The following error is displayed in the browser console:

Error while calling actor 'pagestyle's method 'addNewRule' sheet is null Actor.js:91:13
    writeError resource://devtools/shared/protocol/Actor.js:91
    handler resource://devtools/shared/protocol/Actor.js:187
addNewRule@resource://devtools/server/actors/styles.js:1045:22
handler@resource://devtools/shared/protocol/Actor.js:154:37
onPacket@resource://devtools/server/main.js:1402:58
receiveMessage@resource://devtools/shared/transport/child-transport.js:66:16
Actor.js:96:15
    writeError resource://devtools/shared/protocol/Actor.js:96
    handler resource://devtools/shared/protocol/Actor.js:187

So if I understand correctly, the issue is that "add new rules" creates a <style> element and injects it into the DOM, and CSP that does not include style-src 'unsafe-inline' blocks that.

What we could try to do instead is create a sheet directly and add it to the document. There are Document APIs for doing that for sheets with URIs, declared at https://searchfox.org/mozilla-central/rev/a777ff11b6d700a698c61e5bd17e73b044304494/dom/base/Document.h#2001-2005 and exposed to script via https://searchfox.org/mozilla-central/rev/a777ff11b6d700a698c61e5bd17e73b044304494/dom/interfaces/base/nsIDOMWindowUtils.idl#1623-1658 but those are not a perfect fit: we'd need to synthesize a data: URI or something like that (and ensure that CSP does not block it).

Another option would be to allow adding/removing sheets by just object identity (we have addition already on Document; we'd need to add removal and JS-visible entry points for both) and add a way to create those sheets from a string; the constructible stylesheets proposal might be relevant here. Though we still need to think about how those should interact with CSP...

Emilio, do you have any thoughts when you get back?

Clearing my ni? here after the meeting discussion yesterday.

(In reply to Boris Zbarsky [:bzbarsky, bz on IRC] from comment #20)

What we could try to do instead is create a sheet directly and add it to the document. There are Document APIs for doing that for sheets with URIs, declared at https://searchfox.org/mozilla-central/rev/a777ff11b6d700a698c61e5bd17e73b044304494/dom/base/Document.h#2001-2005 and exposed to script via https://searchfox.org/mozilla-central/rev/a777ff11b6d700a698c61e5bd17e73b044304494/dom/interfaces/base/nsIDOMWindowUtils.idl#1623-1658 but those are not a perfect fit: we'd need to synthesize a data: URI or something like that (and ensure that CSP does not block it).

Another option would be to allow adding/removing sheets by just object identity (we have addition already on Document; we'd need to add removal and JS-visible entry points for both) and add a way to create those sheets from a string; the constructible stylesheets proposal might be relevant here. Though we still need to think about how those should interact with CSP...

IIUC addons right now do the PreloadedStyleSheet dance, minting a data: URI: https://searchfox.org/mozilla-central/rev/a777ff11b6d700a698c61e5bd17e73b044304494/toolkit/components/extensions/ExtensionContent.jsm#268. It'd be great if we used the same thing for both.

Your summary is pretty good. With constructable stylesheets we could do this without much problem, I guess. It's somewhere in the backlog, modulo pending spec issues to be discussed at TPAC.

What do addons do to not get injected <script>s blocked by CSP? Can we do something like that for <style> elements?

What do addons do to not get injected <script>s blocked by CSP? Can we do something like that for <style> elements?

For scripts with src, when we set the src attribute we capture the principal that's doing the set and end up using that principal for the CSP checks.

For inline scripts injected by addons, I expect those would get blocked.

Bug 1520690 may simplify this.

Simplified test case with these Steps to Reproduce:

1. Open devtools Inspector and select any DOM element.
2. In the Rules sub-panel, click the "+" button to add a new rule.

Expected Results:

A new, blank rule is added with a selector matching the DOM element.

Actual Results:

Nothing happens. Browser Console shows this error:

Error while calling actor 'pagestyle's method 'addNewRule' can't access property "cssRules", sheet is null

I'm realizing we can fix this by adding a createElementDevtoolsNS method in Element.webidl, similar to how Bug 1391994 was implemented. I don't know if a constructible stylesheet approach would allow us to do this without adding any new API. For now, I'll build a patch that does it this way (using special principal to inject a DOM style element, which is then parsed) and continue to investigate the constructible stylesheet approach.

(In reply to Brad Werth [:bradwerth] from comment #26)

I'm realizing we can fix this by adding a createElementDevtoolsNS method in Element.webidl, similar to how Bug 1391994 was implemented. I don't know if a constructible stylesheet approach would allow us to do this without adding any new API. For now, I'll build a patch that does it this way (using special principal to inject a DOM style element, which is then parsed) and continue to investigate the constructible stylesheet approach.

I was wrong. createElement is in Document.webidl, and always uses the Document principal to create the new element. There's not an obvious way to impose an alternative principal into the process. Still looking...

D77557 fixes the bug, but is a bit clumsy. I'll still look for a solution that uses constructible stylesheets which ideally won't require a new API to solve this issue.

https://hg.mozilla.org/mozilla-central/rev/7889687e6dbf