User Agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1 Steps to reproduce: User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110302 Iceweasel/3.5.16 (like Firefox/3.5.16) Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0.1) Gecko/20100101 Firefox/4.0.1 Hi. If I use the following (apache) configuration Header set X-Content-Security-Policy-Report-Only \ "allow 'none'; \ report-uri /perl/csp-report.pl" for a document that has inline scripts, no violation reports are generated for them. Sincerely, Sunil Reproducible: Always Expected results: I was expecting a violation report to be generated and sent to the server, however that didn't happen. However, if I do operate with CSP header 'X-Content-Security-Policy' it does correctly prevent the script from execution and also send a violation report.

Does this happen with Firefox 9.0a1?

(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #1) > Does this happen with Firefox 9.0a1? Yes, same behavior is observed in Firefox 6 and Firefox 9.0a1.

Confirming. Specifically, at least in the inline script case we don't log correctly.

pointing to the CSP tracking bug

this is probably because the inline script compiler is asking CSP if it's okay to run the script, and CSP is saying "don't block it" but not telling the caller that a violation report needs to go out. We probably need an outparam in GetAllowsInline (and GetAllowsEval) that returns whether or not it's a violation for when CSP is report-only and not blocking stuff.

bz: I couldn't get this out of my head all morning, so I started on a patch even though I told you I had no time. I'm new at the outparams thing with XPCOM, is this on the right track? I promise to add tests (and confirm it doesn't break CSP or other related unit tests).

Comment on attachment 671654 [details] [diff] [review] wip The outparams bit looks fine, though it may be a good idea to keep the "should I allow this?" as a return value... Note that if you do, I think that will change the order of the two bool* args in C++. Do you still want the JS_ReportError in the setTimeout code? I don't see any callers of SetReportCSPViolations on workers. Should there be some?

(In reply to Boris Zbarsky (:bz) from comment #7) > Do you still want the JS_ReportError in the setTimeout code? Good catch, I don't. Spec says: "When called with a first argument that is non-callable (e.g., not a function), the setTimeout function must return zero without creating a timer." > I don't see any callers of SetReportCSPViolations on workers. Should there > be some? Probably not. I just added it as a reflex (copied the pattern around mEvalAllowed). I'll drop that function. Thanks for the quick feedback.

Addressed all the feedback comments, added tests to test_cspreports.js. It's stewing on try: https://tbpl.mozilla.org/?tree=Try&rev=93501265c67d

Comment on attachment 672965 [details] [diff] [review] proposed patch In dom and content code, this: if (foo) return something; should be written like so: if (foo) { return something; } Please fix the instances of that in this patch, and r=me

So removing the JS_ReportError call destroyed the eval-blocking mochitests. see: http://mxr.mozilla.org/mozilla-central/source/content/base/test/file_CSP_evalscript_main.js I can re-write the tests to check for blocked eval, but without making a racy test I am not sure how to check whether setTimeout executed or not.

Well, a setTimeout with a function argument would still run, right? So if you have: function bar() {} setTimeout("foo", n); setTimeout(bar, n); then you're guaranteed that the string "foo" will NOT be eval'ed after function bar is called.

Updated patch with "eval" tests that should work based on the pattern suggested by bz. For some reason I remember being told that order of execution was not guaranteed for two timeouts with the same interval. Seems to work though, we'll see if try likes it. https://tbpl.mozilla.org/?tree=Try&rev=f162b743fd2e I only found one instance of "if (foo) bar;", but fixed it as requested in comment 10. Carrying over r=bz.

>+ if (!allowsInline) return NS_ERROR_DOM_RETVAL_UNDEFINED; in nsJSThunk::EvaluateScript.

This is no longer blocked by bug 552523 (works without it).

(In reply to Boris Zbarsky (:bz) from comment #14) > >+ if (!allowsInline) return NS_ERROR_DOM_RETVAL_UNDEFINED; > > in nsJSThunk::EvaluateScript. *sigh*, thanks bz. My copy of Eyeball Grep is apparently not working today. I'll fix that and reattach after try gets back to me with a thumbs up or down.

Need to unbitrot and make sure it doesn't break new stuff.

Unbitrotted and carrying over r=bz. Also addressed the failure of my eyegrep. Try: https://tbpl.mozilla.org/?tree=Try&rev=bdfa3da43011

Inbound: https://hg.mozilla.org/integration/mozilla-inbound/rev/c29279c95238