Document aRequestPrincipal in nsIContentPolicy.idl

RESOLVED FIXED in mozilla19

Status

()

defect
RESOLVED FIXED
7 years ago
7 years ago

People

(Reporter: devd, Assigned: devd)

Tracking

({addon-compat, dev-doc-needed})

unspecified
mozilla19
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

Assignee

Description

7 years ago
Bug 767134 didn't add documentation. Add required documentation. This might also mean more crisply defining what the aRequestPrincipal should be for all the contentpolicy calls.
Assignee

Updated

7 years ago
Assignee: nobody → dev.akhawe+mozilla
Assignee

Comment 1

7 years ago
Assignee

Updated

7 years ago
Attachment #673500 - Flags: review?(bzbarsky)
Assignee

Comment 2

7 years ago
First attempt. Not sure what the documentation etiquette is, but I am sure the review will point me towards the right path.
Comment on attachment 673500 [details] [diff] [review]
Documentation for aRequestPrincipal

>+   *                          inapplicable. Note that loads caused by data:
>+   *                          and about: iframes pass the iframe URI as the
>+   *                          requestOrigin, but the iframe inherits the
>+   *                          principal from the parent by default.

Is this necessarily true?  I think this is true for navigation, but not for, say, an <img> load in such an iframe, since that goes through NS_CheckContentLoadPolicy, which passes in the principal codebase as the location.

Also, javascript: has the same behavior as data:.  And about: generally does not; about:blank is special.

>+   *                          argument. Currently, not set for any loads other
>+   *                          navigation events.

"other than"?

But this seems to not be the case; anything using NS_CheckContentLoadPolicy is passing in a principal.

r=me with the above fixed.
Attachment #673500 - Flags: review?(bzbarsky) → review+
Assignee

Updated

7 years ago
Attachment #673500 - Attachment is obsolete: true
Assignee

Comment 5

7 years ago
Comment on attachment 674542 [details] [diff] [review]
Documentation for aRequestPrincipal

r=bz

Carrying over the r+ from bz. 

@bz: If you have time to take a look and confirm that the documentation looks right, that would be great. I will wait for a couple of days before requesting check-in.
Attachment #674542 - Flags: review+
Looks reasonable.
Assignee

Updated

7 years ago
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/dff2047ef68e
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Flags: in-testsuite-
Resolution: --- → FIXED
Target Milestone: --- → mozilla19
In which cases would the caller be non-gecko code?
Assignee

Comment 10

7 years ago
Any extension (e.g., noscript, adblock)

There might be other cases. bz/dveditz probably know more.
Is there a bug to go through the code and add the Request Principal in gecko code when it's missing?
Assignee

Comment 12

7 years ago
If I am not wrong, Gecko code should be using NS_CheckContentLoadPolicy anyways, and that should set the requestprincipal properly. Can you point me to examples where it's missing?
You need to log in before you can comment on or make changes to this bug.