Closed Bug 1399436 Opened 7 years ago Closed 6 years ago

CSP error output could be better

Categories

(DevTools :: Console, defect, P3)

defect

Tracking

(firefox57 wontfix)

RESOLVED DUPLICATE of bug 1279894
Tracking Status
firefox57 --- wontfix

People

(Reporter: julienw, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: parity-chrome)

Attachments

(1 file)

Attached file testcase-csp.html (deleted) —
STR: 1. Open attachment. 2. Open the Console. The current error in the console is: Content Security Policy: The page’s settings blocked the loading of a resource at self (“default-src file://”). Source: body:before { content: 'This was inse.... Content Security Policy: The page’s settings blocked the loading of a resource at self (“default-src file://”). Source: document.body.appendChild( document.c.... Compare this with Chrome Console output: Refused to apply inline style because it violates the following Content Security Policy directive: "default-src 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-R4hrL5kYgiWYDU7vxI2haXt5hosU4JGdW+dqkbQQM5U='), or a nonce ('nonce-...') is required to enable inline execution. Note also that 'style-src' was not explicitly set, so 'default-src' is used as a fallback. Refused to execute inline script because it violates the following Content Security Policy directive: "default-src 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-q2cjDVAEq5Vq6q3K379a8koE3c/BueHSGGmWUF9/2nM='), or a nonce ('nonce-...') is required to enable inline execution. Note also that 'script-src' was not explicitly set, so 'default-src' is used as a fallback. Several things are better in Chrome output: 1. The error's actual text is better. I was gonna say "less technical" but it's not true, it's just better text. Like somebody redacted it as opposed to a machine spewed it out. 2. There are some explanations about how to fix the error. It would be better with a link to MDN of course ;) 3. I also especially like the last sentence where the fallback mechanism is explained as well. In Firefox output, it's something we need to guess. Especially in Firefox output we don't even know the _type_ of the blocked ressource. This makes working on a CSP configuration much much easier with Chrome.
Christoph - I feel like we may have discussed this before, but I can't find a bug. Maybe it's time to revisit the text of the CSP error message? I definitely like the idea of adding an MDN link for these, and it's pretty easy without even touching the frontend by setting a category on the message and then a link in https://dxr.mozilla.org/mozilla-central/source/devtools/server/actors/errordocs.js#97. I'm not sure how targeted the MDN page(s) should be in this case - ideally we could point to a single page that includes details on how to fix most common errors instead of adding a new category for every directive.
Flags: needinfo?(ckerschb)
Priority: -- → P3
(In reply to Brian Grinstead [:bgrins] from comment #1) > Christoph - I feel like we may have discussed this before, but I can't find > a bug. Maybe it's time to revisit the text of the CSP error message? Brian, I agree that our CSP console logging is not that grisp, and I would really like to improve that. I am marking this bug blocking Bug 1242016, which is the umbrella bug for improving CSP console logging. Hopefully I can get someone to work on this soon. Thanks!
Flags: needinfo?(ckerschb)
Product: Firefox → DevTools

Duping with bug 1279894 as it already has a patch to add more helpful messages.

Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE

A patch from 3y ago, I doubt it still works :(

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: