Currently it calls into XPConnect, which uses the most recent XPCCallContext. But for consumers on new bindings, this answer is no longer correct. In particular, I'm worried about NS_NewHTMLOptionElement and NS_NewHTMLImageElement, both of which are on new bindings (I believe) and use GetDocumentFromCaller to determine NodeInfo. I'm not sure what kind of nastiness can be done with an incorrect NodeInfo, but I'm CCing moz_bug_r_a4 in case it proves fruitful. I'm rewriting this function in one of my patches in bug 883450.

NS_NewHTMLOptionElement and NS_NewHTMLImageElement got called with null aNodeInfo from CreateHTMLOptionElement and CreateHTMLImgElement. These can only be invoked when constructing them via contractid or classid. So first of all, in that situation we will in fact be coming from XPConnect and have an XPCCallContext. Second, this used to be done by the |new Option| and |new Image| stuff, but now those are WebIDL constructors. So I think we should just rip out the contract/classids for option and image, rip out the Create methods in nsLayoutModule.cpp, and rip out the special-casing in the NS_New methods: make them assume aNodeInfo is not null. This is all dead code as far as the web is concerned.

Fully support removing support for contractid/classid for Img and Option.

OK, let's morph this to cover that removal and this is not a security issue.

Could you still check if some addon uses those contractids

I did before writing the patch: no hits in the addons mxr. Can't speak to binary addons...