Closed Bug 792542 Opened 10 years ago Closed 10 years ago

CSPRep.fromString creates a channel out of thin air


(Core :: DOM: Core & HTML, defect)

Not set



Tracking Status
firefox18 + fixed


(Reporter: jdm, Assigned: jdm)


(Blocks 1 open bug)



(1 file)

This looks like it should be assigned the same loadgroup as the originating document to prevent information leakage in private browsing.
It used to be a chrome XHR, but that got changed in bug 558431.  But yeah, it should probably be in the same loadgroup as the document for purposes of private browsing.
Blocks: CSP
Component: DOM → DOM: Core & HTML
Assignee: nobody → josh
Sid, I would love to write a test for this but I couldn't find any examples of tests that do things with valid async policy-uri directives. If you can give me some pointers, the code to check whether the request is cached correctly is simple.
Attachment #663260 - Flags: review?(sstamm)
Comment on attachment 663260 [details] [diff] [review]
Make CSP report channel respect the privacy status of the original request.

Review of attachment 663260 [details] [diff] [review]:


Note: your patch comment has r=sstam in it (should be r=sstamm or r=geekboy).

I think the patch in bug 558431 has xpcshell async policy-uri tests -- see the patch to test_csputils.js and test_bug558431.js.  I'd love to have tests for this if you can.
Attachment #663260 - Flags: review?(sstamm) → review+
It doesn't look like it's going to be a simple task to write a test for this - in xpcshell we can run a server on the policy port, but then we don't have a document and loadgroup and so forth. We can't easily run a server in something like mochitest-browser-chrome, as far as I know, so I think I'm going to have to punt on automatic tests.

Should this have a test?
Closed: 10 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Target Milestone: --- → mozilla18
Can someone provide some STR so I can verify this fix please?
You need to log in before you can comment on or make changes to this bug.