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
We've solved issue #1. See bug 40406.
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