1228985 - "Add new rule" is blocked by CSP

Status: RESOLVED FIXED

(DevTools :: Inspector: Rules, defect, P2)

Description

[Tim Nguyen :ntim]

13:30:09.798 TypeError: sheet is null
Stack trace:
PageStyleActor<.addNewRule<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/styles.js:981:9
TaskImpl_run@resource://gre/modules/Task.jsm:314:40
TaskImpl@resource://gre/modules/Task.jsm:275:3
createAsyncFunction/asyncFunction@resource://gre/modules/Task.jsm:249:14
actorProto/</handler@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/protocol.js:1013:19
DSC_onPacket@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/main.js:1643:15
LocalDebuggerTransport.prototype.send/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/transport/transport.js:569:11
makeInfallible/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/DevToolsUtils.js:87:14
makeInfallible/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/DevToolsUtils.js:87:14
1 protocol.js:907

Comment 1

[Tim Nguyen :ntim]

Doesn't work in 42 or 45, haven't tested on other version, but I'm pretty sure it doesn't work on 43 or 44.

Comment 2

[Tim Nguyen :ntim]

So it looks like one of the stylesheets doesn't exist on the page.

:gl, :tromey, any idea why this might be failing ?

Comment 3

[Patrick Brosset <:pbro>]

This still doesn't work in FF47.
It actually comes from a CSP policy on this site (style-src).
https://developer.mozilla.org/fr/docs/Web/Security/CSP/CSP_policy_directives#style-src

The headers on this page define this CSP and this blocks the creation of inline <style> sheet.
However, the "add rule" feature depends on this.

I think we've had this problem already in the past and I seem to remember that CSP policies were not supposed to apply to devtools code. But I can't remember the exact bug where this was discussed.

I'm tempted to triage this as a P1, but I don't know if we have the bandwidth at the moment to investigate and solve this potentially complex problem, and this has been here for a while and hasn't had really bad consequences from what I can see.

I'll try to ping a few people, hopefully I get a lead on how to start fixing this.

Comment 4

[Patrick Brosset <:pbro>]

This is similar to bug 1185351 which was about the highlighter. The highlighter sets style attributes on dynamically injected native anonymous content in the page, and this used to be blocked by CSP. Bug 1185351 basically made CSP ignore native anon content.

Here, we're not using native anon content, devtools is creating a (normal) <style> DOM node to inject new rules that the user is creating in the inspector.

According to https://en.wikipedia.org/wiki/Content_Security_Policy#Browser_add-ons_and_extensions_exemption browser code should be exempt from this.

Christoph: how should we proceed here? It looks like a CSP bug.

Comment 5

[Christoph Kerschbaumer [:ckerschb]]

(In reply to Patrick Brosset [:pbro] from comment #4)
> Here, we're not using native anon content, devtools is creating a (normal)
> <style> DOM node to inject new rules that the user is creating in the
> inspector.

Right, so applying the same fix as within Bug 1185351 where we just used | IsInNativeAnonymousSubtree() | doesn't apply here. 

> Christoph: how should we proceed here? It looks like a CSP bug.

I don't think it's a CSP bug though, but you are right, we should not apply CSP when adding a rule. Ehsan probably knows how we can exempt such loads from CSP. Ehsan, any ideas?

Just for the sake of completeness, here is the CSP error I receive in the console:
> Content Security Policy: The page's settings blocked the loading of a resource at self ("style-src http://vosteran.com").

However, I get a slightly different stacktrace, see below:

console.error: 
  Error writing response to: addStyleSheet
*************************
A coding exception was thrown in a Promise resolution callback.
See https://developer.mozilla.org/Mozilla/JavaScript_code_modules/Promise.jsm/Promise

Full message: TypeError: this.rawSheet is null
Full stack: StyleSheetActor<.ownerNode@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/stylesheets.js:441:5
StyleSheetActor<.form@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/stylesheets.js:581:1
types.addActorType/type<.write@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/protocol.js:294:44
RetVal<.write@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/protocol.js:529:12
Response<.write/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/protocol.js:682:16
Response<.write@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/protocol.js:680:23
actorProto/</handler/sendReturn@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/protocol.js:1023:24
Handler.prototype.process@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:937:23
this.PromiseWalker.walkerLoop@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:816:7
Promise*this.PromiseWalker.scheduleWalkerLoop@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:747:11
this.PromiseWalker.schedulePromise@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:779:7
Promise.prototype.then@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:454:5
actorProto/</handler/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/protocol.js:1043:18
Actor<._queueResponse@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/protocol.js:920:20
actorProto/</handler@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/protocol.js:1042:9
DSC_onPacket@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/main.js:1643:15
LocalDebuggerTransport.prototype.send/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/transport/transport.js:569:11
exports.makeInfallible/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/ThreadSafeDevToolsUtils.js:101:14
exports.makeInfallible/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/ThreadSafeDevToolsUtils.js:101:14

*************************
console.error: 
  Message: TypeError: this.rawSheet is null
  Stack:
    StyleSheetActor<.ownerNode@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/stylesheets.js:441:5
StyleSheetActor<.form@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/stylesheets.js:581:1
types.addActorType/type<.write@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/protocol.js:294:44
RetVal<.write@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/protocol.js:529:12
Response<.write/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/protocol.js:682:16
Response<.write@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/protocol.js:680:23
actorProto/</handler/sendReturn@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/protocol.js:1023:24
Handler.prototype.process@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:937:23
this.PromiseWalker.walkerLoop@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:816:7
Promise*this.PromiseWalker.scheduleWalkerLoop@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:747:11
this.PromiseWalker.schedulePromise@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:779:7
Promise.prototype.then@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:454:5
actorProto/</handler/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/protocol.js:1043:18
Actor<._queueResponse@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/protocol.js:920:20
actorProto/</handler@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/protocol.js:1042:9
DSC_onPacket@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/main.js:1643:15
LocalDebuggerTransport.prototype.send/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/transport/transport.js:569:11
exports.makeInfallible/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/ThreadSafeDevToolsUtils.js:101:14
exports.makeInfallible/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/ThreadSafeDevToolsUtils.js:101:14

StyleSheetActor<.ownerNode@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/stylesheets.js:441:5
StyleSheetActor<.form@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/stylesheets.js:581:1
types.addActorType/type<.write@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/protocol.js:294:44
RetVal<.write@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/protocol.js:529:12
Response<.write/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/protocol.js:682:16
Response<.write@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/protocol.js:680:23
actorProto/</handler/sendReturn@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/protocol.js:1023:24
Handler.prototype.process@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:937:23
this.PromiseWalker.walkerLoop@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:816:7
Promise*this.PromiseWalker.scheduleWalkerLoop@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:747:11
this.PromiseWalker.schedulePromise@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:779:7
Promise.prototype.then@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:454:5
actorProto/</handler/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/protocol.js:1043:18
Actor<._queueResponse@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/protocol.js:920:20
actorProto/</handler@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/protocol.js:1042:9
DSC_onPacket@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/main.js:1643:15
LocalDebuggerTransport.prototype.send/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/transport/transport.js:569:11
exports.makeInfallible/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/ThreadSafeDevToolsUtils.js:101:14
exports.makeInfallible/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/ThreadSafeDevToolsUtils.js:101:14

Comment 6

[(no longer active)]

(In reply to Christoph Kerschbaumer [:ckerschb] from comment #5)
> > Christoph: how should we proceed here? It looks like a CSP bug.
> 
> I don't think it's a CSP bug though, but you are right, we should not apply
> CSP when adding a rule. Ehsan probably knows how we can exempt such loads
> from CSP. Ehsan, any ideas?

Comment 0 contains 0 information about what this bug is about, and how the stacktrace there (or the ones in comment 5) are captured.  Unfortunately I don't understand this bug at all, so I can't really answer this question in any useful way.

Can you please express the question in a self-contained paragraph?  :)

Comment 7

[Tim Nguyen :ntim]

Ehsan, sorry for the lack of precision, here are some STR:
- Go to http://vosteran.com
- Open inspector
- Click the '+' icon next to 'Filter Styles'

See how nothing happens (no rule is created). The stack trace can be captured simply by opening the Browser Toolbox.

Comment 8

[Christoph Kerschbaumer [:ckerschb]]

(In reply to Tim Nguyen [:ntim] from comment #7)
> Ehsan, sorry for the lack of precision, here are some STR:
> - Go to http://vosteran.com
> - Open inspector
> - Click the '+' icon next to 'Filter Styles'
> 
> See how nothing happens (no rule is created). The stack trace can be
> captured simply by opening the Browser Toolbox.

Thanks Tim for the STR.

Ehsan, basically the problem is that the site's CSP applies to devtools code, but devtools code should be exempt from the site's CSP. We had a similar problem within Bug 1185351, where using |IsInNativeAnonymousSubtree()| fixed the problem and the site's CSP did not apply to devtools code anymore.

The problem here is slightly different though, because we are not using native anon code. Devtools code is rather creating a regular <style> DOM Node which allows injecting new user rules created through the inspector. I added a stacktrace within Comment 5 (see also original stacktrace in Comment 0).

Any idea how we can exempt such DOM Node creations from being blocked by CSP?

Comment 9

[(no longer active)]

As far as I know, there is no real difference between a style element added by devtools code versus one added by the web page itself, so as things stand, there is no way to differentiate on the source of the style element, and therefore it's impossible to make it not be subject to the site's CSP.  The case of a node in a native anonymous subtree is different since native anonymous subtrees are not exposed to the web page script, so there's no way for such an element to come from the web page.

It seems like in this case, devtools needs to do something different.  Injecting nodes into the DOM is not really OK since those nodes will be visible to the web page script, they can change the meaning of CSS selectors, etc.

Comment 10

[Patrick Brosset <:pbro>]

Worth noting: clicking on the "new" button in the style-editor to create a new stylesheet also fails on this site for the same reason.
Here are the interesting parts of the errors displayed in the console when this happens:

> Error writing response to: addStyleSheet protocol.js:1025
> 
> Content Security Policy: The page's settings blocked the loading of a resource at self ("style-src http://vosteran.com")./:1
> 
> Full Message: Protocol error (unknownError): this.rawSheet is null

The style-editor tries to create an inline stylesheet in the page just like when using the "Add rule" button in the inspector.

Interestingly, this works fine in Chrome even if they also insert a <style> element in the DOM.

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.

Comment 11

[(no longer active)]

Yeah, doing something along those lines is a good idea.  I'm not sure how the add-on SDK stylesheet API works but the presshell supports a number of APIs for loading various types of stylesheets without injecting style nodes into the DOM: <https://dxr.mozilla.org/mozilla-central/source/layout/base/nsPresShell.h#582>  Some of these (IIRC the agent stylesheets for example) are exposed from nsIPresShell, and we can expose more of them if needed.

Comment 13

[Brad Werth [:bradwerth]]

The fix here will likely be similar to the fix for Bug 1391994.

Comment 14

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

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

Comment 15

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

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

Comment 16

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

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

Comment 17

[:Harald Kirschner :digitarald]

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.

Comment 18

[Christoph Kerschbaumer [:ckerschb]]

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

Comment 19

[Patrick Brosset <:pbro>]

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

Comment 20

[Boris Zbarsky [:bzbarsky]]

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?

Comment 21

[Christoph Kerschbaumer [:ckerschb]]

Clearing my ni? here after the meeting discussion yesterday.

Comment 22

[Emilio Cobos Álvarez (:emilio)]

(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?

Comment 23

[Boris Zbarsky [:bzbarsky]]

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.

Comment 24

[Brad Werth [:bradwerth]]

Bug 1520690 may simplify this.

Comment 25

[Brad Werth [:bradwerth]]

Attachment: csp_style_src_none.html

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

Comment 26

[Brad Werth [:bradwerth]]

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.

Comment 27

[Brad Werth [:bradwerth]]

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

Comment 28

[Brad Werth [:bradwerth]]

Attachment: Bug 1228985 Part 1: Extend HTMLStyleElement to allow devtools to become the triggering principal.

Comment 29

[Brad Werth [:bradwerth]]

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.

Comment 30

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/7889687e6dbf
Part 1: Extend HTMLStyleElement to allow devtools to become the triggering principal. r=ckerschb,emilio

Comment 31

[Cosmin Sabou [:CosminS]]

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