Closed Bug 490788 Opened 15 years ago Closed 15 years ago

Content policy calls for XBL resources don't allow checking the document loading XBL

Categories

(Core :: XBL, defect)

defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: jwkbugzilla, Unassigned)

References

Details

As it is implemented now, XBL will issue content policy calls for images and stylesheets listed in the <resources> section - but the only context given will be the XML document of the binding itself. From what I can tell, there is no way to get to the document in which the binding is applied. Getting there from the channel or the load group would be possible but neither is exposed on any scriptable interface. Neither is document container exposed (not sure whether this would allow going to parent document anyway).
Assuming you've already processed the XBL document in a previous shouldLoad() call, you could work around by annotating the parent document in an expando property (which would be visible only from chrome thanks to wrappers) of the XBL document itself, couldn't you?
No, because you usually never get to see the XBL document - unless you call loadBindingDocument() yourself. The shouldLoad() call for the XBL binding itself passes in the document initiating the load as context. The XBL document doesn't even exist at that point.
Binding prototype documents are shared across multiple documents, so there's really no better context that can be passed in here...  That is, there is no "the" document to which the binding is (or rather will be, once it finishes loading) applied.  There might be more than one such document.
That's what I guessed by looking at the source code. What doesn't quite fit into the picture however is nsXBLService::FetchBindingDocument() - apparently, there is a document there and the binding (as well as its resources I guess) is loaded with the load group of this document. The other thing is that I cannot find evidence of this sharing of bindings - if I open two documents using the same binding in two tabs I see two content policy calls for the image resource specified in the binding (no actual requests being made because everything is cached). Or does sharing only apply to chrome bindings?
Yeah, FetchBindingDocument loads the XBL in the loadgroup of the first document that asks for it, but we coalesce any later loads with that.  And yes, that's somewhat broken.

We do the security check (including the content policy call) for the load before coalescing, because a given binding may be allowed to be loaded by one document but not another one...
Yeah, we don't want people to make security decisions based on the first document to happen to use a binding, since those decisions will then apply for all future documents. So I don't think there's much more context we can give here unfortunately.

What problems does this result in?
Too bad. Thanks for the explanation. => WONTFIX
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.