While playing with my testcase in attachment 9307131 [details] for bug 1804210 I noticed that injecting an inline style element with a mismatched nonce triggered way more console warnings and corresponding SecurityPolicyViolation events than I expected.

STR:

1. open attachment 9307131 [details] and open the DevTools Console
2. Note right off the bat there are 8 "lineless" script-src Report-only errors, followed by a single script-src report-only error on line 20 of about:srcdoc (this comes from the bmoattachments.org CSP). The testcase has only a single inline <script> in it.
3. press the "parent head.innerHTML (no nonce)" button which adds a single style block to the document which the nonce-requiring CSP will block.
   ==> note there were 4 errors given
4. press it again
   ==> 16? There are two headers now so 4*2 sorta makes sense, plus the 4 we already had is 12. where did the extra 4 come from?
5. press it again
   ==> 40! if you use the inspector you can see there are the expected three nonceless (error triggering) style elements, but we get 24 new warnings when the head is re-parsed. That's 8 warnings per inline element when we started at 4.

The console warnings aren't such a big deal since they get collapsed, but each of those also represents a SecurityPolicyViolation sent to the page and, worse, potentially an error sent to the report-uri. You can verify the events are happening by executing the following in the console

  window.addEventListener("securitypolicyviolation", (e)=>console.log(e));

There were extra CSP parser warnings in bug 1645745, but that seemed to involve the need to use the policy in both the parent and content processes. I think document parsing should all happen in a single content process. This might not be a CSP problem at all; could it be revealing that we reparse parts of the document waaaay too much? There might be a nice perf win hiding here.

I haven't tried

We already have Bug 1657519 for coalescing reports. We do re-parse CSP policies sometimes, for example for the frame-ancestor check in the parent and when serializing the CSP for IPC. I am reducing the produced warnings from that in bug 1645745.

bug 1657519 is about coalescing reports on a page that had tons of the same kind of error, but did in fact generate those errors in different places. On this one I injected a single Style tag and should have generated only a single error. bug 1657519 is for developer convenience; this one is a flaw in Firefox.

Would it be the same fix?

2. Note right off the bat there are 8 "lineless" script-src Report

These are actually the inline event handlers, which becomes obvious with bug 1804038 fixed.

Content Security Policy: The page’s settings observed the loading of a resource at inline (“script-src”). A CSP report is being sent.
Source: inner() srcdoc
Content Security Policy: The page’s settings observed the loading of a resource at inline (“script-src”). A CSP report is being sent.
Source: inner(NO_NONCE) srcdoc
Content Security Policy: The page’s settings observed the loading of a resource at inline (“script-src”). A CSP report is being sent.
Source: makeNode(parent.document) srcdoc
Content Security Policy: The page’s settings observed the loading of a resource at inline (“script-src”). A CSP report is being sent.
Source: makeNode(document) srcdoc
Content Security Policy: The page’s settings observed the loading of a resource at inline (“script-src”). A CSP report is being sent.
Source: makeNode(parent.document,MATCH_DOC) srcdoc
Content Security Policy: The page’s settings observed the loading of a resource at inline (“script-src”). A CSP report is being sent.
Source: makeNode(document,MATCH_DOC) srcdoc
Content Security Policy: The page’s settings observed the loading of a resource at inline (“script-src”). A CSP report is being sent.
Source: cssom(parent.document) srcdoc
Content Security Policy: The page’s settings observed the loading of a resource at inline (“script-src”). A CSP report is being sent.
Source: cssom(document)

3. I am not sure why we get 4 style-src errors by default, I am going to have to debug that.

4ff. All of this exponential increase comes from using innerHTML with +=, which means we reparse everything that we already had as innerHTML PLUS the new string.

During parsing we do seem to call nsCSPContext::GetAllowsInline from nsStyleUtil::CSPAllowsInlineStyle four times for the same element.

At least once or twice from nsHtml5DocumentBuilder::UpdateStyleSheet and then also LinkStyle::UpdateStyleSheetInternal from some kind of runnable?