Hmm. We create an initial wrapper when we attach the Components object to the window. The security check is bypassed then. But we also have to do the CanCreateWrapper check every time we build a tearoff - i.e. each time we QI the underlying native object to some particular interface. We'd have to do some real debugging to discover the source of the anomoly jst uncovered. bug 79916 was masking the problem for a short while I expect. but that's been fixed for a few weeks now. I don't really care if you go with jst's patch (and look into the other nsISecurityCheckedComponent::CanCreateWrapper cases for similar problems) or just decide to allow the creation of all wrappers in the security manager - that would be Mitch's decision.
I'm thinking about allowing all wrapper creation. jband tells me this was added as belt-and-suspenders protection, and while it's good to have additional lines of defense, this security check seems to be causing errors in a number of unexpected places. Let me throw out this question one last time, to whoever has an opinion on it: If a script can create a wrapper for an object but can't call any methods or access any properties on that wrapper, what can the script do with the wrapper? What access is gained?
sr=jband on jst's patch. Even if you change the security manager to never call this, it is a good change on its own.
Created attachment 37119 [details] [diff] [review] ensure wrapper creation allowed for nsJSIID too (includes jst's patch)
r=dbradley for the combined patch
The patch looks fine to me. r=mstoltz too.
a=blizzard on behalf of drivers for the trunk
Patrick, I'm adding you since we'll have to do the checkin.