When starting up mozilla/Netscape and typing javascript:Node.TEXT_NODE; we end up getting a "Node is not defined" on the JS console, and if you type javascript:Components.interfaces; in the URL bar you get an "Permission denied to create wrapper for object" (which is what accessing Node.XXX does underneeth the covers). Now, the interesting thing is that once you've run mozilla for a while accessing Node.XXX works w/o problems, why, I have no idea. I tracked down the problem when you start up mozilla and try to access Components.interfaces and the problem goes away if I XPConnect allows creating a wrapper for Components, this patch makes the problem go away: Index: js/src/xpconnect/src/xpccomponents.cpp =================================================================== RCS file: /cvsroot/mozilla/js/src/xpconnect/src/xpccomponents.cpp,v retrieving revision 1.40 diff -u -r1.40 xpccomponents.cpp --- xpccomponents.cpp 2001/05/23 00:12:04 1.40 +++ xpccomponents.cpp 2001/06/03 01:00:07 @@ -1762,8 +1762,8 @@ NS_IMETHODIMP nsXPCComponents::CanCreateWrapper(const nsIID * iid, char **_retval) { - // If you have to ask, then the answer is NO - *_retval = nsnull; + // If you have to ask, then the answer is YES + *_retval = CloneAllAccess(); return NS_OK; } Interestingly enough, if I do: javascript:Components; before trying either: javascript:Components.interfaces; or javascript:Components.Node.ELEMENT_NODE; I *don't* see this problem. How is this possible? What should we do to fix this, apply my patch, or skip the security checks when creating wrappers (as we've discussed before)? Or something else? We need to get this solved for mozilla0.9.2.

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.

r=dbradley for the combined patch

sr=jst

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.

Checked in.

Marking Verified Fixed. Using debug WinNT build 2001-06-19. I can start up Mozilla from scratch, and access both javascript:Node.TEXT_NODE; (= 3) and javascript:Components.interfaces; (= [object nsXPCComponents_Interfaces])