Steps to Reproduce:

1. Navigate to about:blank.
2. Open the Browser Console and clear it.
3. Open Devtools Inspector.

Expected Results:

Nothing appears in the Browser Console.

Actual Results:

Content Security Policy: The page’s settings blocked the loading of a resource at inline (“default-src”). panel.js:78

This is leading to confused reporting of CSP issues in unrelated bugs.

Here's a more complete JS stack when this CSP error is hit:

0 initialize() ["chrome://global/content/elements/panel.js":78:24]
    this = [object XULPopupElement]
1 connectedCallback() ["chrome://global/content/elements/panel.js":46:13]
    this = [object XULPopupElement]
2 HTMLTooltip(toolboxDoc = "[object HTMLDocument]", (destructured parameter) = "[object Object]") ["resource://devtools/client/shared/widgets/tooltip/HTMLTooltip.js":404:29]
    this = [object Object]
3 initializeTooltip() ["resource://devtools/client/shared/components/menu/MenuButton.js":175:19]
    this = [object Object]
4 MenuButton(props = "[object Object]", "[object Object]") ["resource://devtools/client/shared/components/menu/MenuButton.js":115:9]
5 constructClassInstance(workInProgress = "[object Object]", ctor = [function], props = "[object Object]", renderExpirationTime = "1073741823") ["resource://devtools/client/shared/vendor/react-dom.js":8270:17]
6 updateClassComponent(current$$1 = "null", workInProgress = "[object Object]", Component = [function], nextProps = "[object Object]", renderExpirationTime = "1073741823") ["resource://devtools/client/shared/vendor/react-dom.js":10592:26]

This has some interesting similarities with Bug 1228985, in that the failed resource load is from a style element with no triggering principal. Which style element it is, and what created it I'm not clear yet. If the style element had a triggering principal upon creation, it would load without a CSP error.

Style element seems to be created by menupopup.js and instantiated when the tooltip is added to the document in the HTMLTooltip constructor. The style element is created with no triggering principal. Part of the problem is that HTMLStyleElement::BindToTree does not set the principal before triggering the initial update of the stylesheet. When that update happens, there's no principal, so inline style is blocked by -- I think -- the CSP declaration for the devtools application.
Edit -- that is not the relevant CSP declaration. The CSP is associated with the "about:devtools-toobox" document, and is declared in devtools/client/framework/toolbox.xhtml.

Depends on D77721

The proposed solution here involves two parts:

1. Associating a system principal with the inline style tags created when devtools is rendered.
2. Making system principals allow inline style by default.

I've proposed the second change before, in another bug where we were trying to allow devtools to edit inline style on pages with a CSP. Instead, in that case, we added a flag to a CSP object to skip the inline check. Here is another case where, if system principals skipped the inline style check, we would get a helpful result. Is this an acceptable change to the behavior of the inline style check? If not, what sort of security problems would it create?

Looks good to me, but I'm not an expert to answer this question. Pass the ball to baku.

This was a surprising regression result. I expected that the CSP added around the same time in Bug 1577446 would be responsible, but apparently not.

Are these 2 patches ready to be reviewed? Do you mind adding them to my review queue? Thanks.

(In reply to Andrea Marchesini [:baku] from comment #9)

Are these 2 patches ready to be reviewed? Do you mind adding them to my review queue? Thanks.

Thank you for offering to review. I'm not sure this is the right approach yet. I want to understand the regressing bug better first, as well as understand which CSP is being applied when the triggering principal is null -- I'm not yet confident that it is the CSP mentioned in comment 3.

I'm exploring alternatives. One way to solve this would be to change the CSP declared in devtools/client/framework/toolbox.xhtml. When I do that, we hit an assert in nsContentSecurityUtils::AssertAboutPageHasCSP which enforces that "about:" pages can't have inline-src.

Another idea is to prevent the XUL parser from using injected style tags, and instead inject link tags that point to approved CSS files. I'll see if I can put together a patch that does that. It might be non-trivial for me, in which case I'll seek approval of my original approach, because I don't have any other proposals on how to solve this.

This supports the fact that devtools, which is hosted in an "about:" page,
does not use inline styles. They are prevented from working by the CSP defined
at devtools/client/framework/toolbox.xhtml. This patch moves The styles that
are added by the MozPanel.initialize method into the popup.css files for each
theme, where the other .panel-arrowcontent class selectors live.

https://hg.mozilla.org/mozilla-central/rev/431597af517c

The patch landed in nightly and beta is affected.
:bradwerth, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

Confirmed issue with 77.0.1 on Windows 10.
Verified fix with 79.0b3 on Windows 10, macOS 10.15.5, Ubuntu 18.