Many people have helped a lot to make xpconnect play nice with DOM objects. xpcconvert.cpp in xpconnect has code that does its best to wrap and unwrap DOM objects used in xpconnect calls. Work was also done to decrease the extent to which the DOM makes assumptions about DOM code only being called on JSContexts which it created itself. But, there remain cases where these two system do not get along... 1) As mscott struggled with recently, xpconnect can not convert a native DOM object into a JSObject if neither the static or dynamic scope chain connect to any wrapped DOM objects. In his case he had a JS component (xpconnect) code that was calling a native service to get the "most recent" nsIWindow (a DOM object). XPConnect had no way to access an nsIScriptContext needed in order to get the JSObject wrapper from the native nsIWindow object. 2) There remain some methods in the DOM system that will not work properly if not called on a DOM JSContext. For instance, window.open tries to use the global object of the running JSContext in order to figure out the base URL in constructing the absolute URL to open. Ultimately, I'm afraid that these sorts of issues can not be 100% solved until the DOM is converted to use xpconnect rather than the idlc generated code system.
XPConnect flattening and DOM conversion to use XPConnect is on the way. It may not fix everything because there will still be JSContexts in the system not created by the DOM. And I don't think we are going to 'fix' all the code that tries to determine the "caller window" by looking at the JSContext.
fixed by XPCDOM_20010329_BRANCH landing