Open Bug 433711 Opened 16 years ago Updated 1 year ago
Unable to wrap interface for DOM object when interface is not in classinfo (ns
Http Channel::Install Cache Listener init fails when listener is a DOM object and tee is implemented in JS)
I have created a test-case see: http://www.janodvarko.cz/firebug/tests/Issue679.htm It should be easy to reproduce the problem with FB 1.2.0a27. If it would make things easier I can provide a simple FF extension that shows the problem too.
Is it possible to handle the nsXMLHttpRequest case with another mechanism as a workaround to make this workaround work?
The only workaround that occurs to me is to implement the new tee-listener component in C++. In such a case the conversion (of method parameters) into JS would not be performed and it could work as expected. Just to note that this approach isn't necessary for XHRs. It's actually easy to get response body from a XHR (there is responseText property in nsIXMLHttpRequest, this is used by e.g. spy.js). This approach is used mainly for requests made by a page during the load time. Unfortunately I don't see any way how to "switch off" this approach just for XHRs...
Hmm. It seems like this should just work, since nsXMLHttpRequest implements nsIStreamListener, but there's been some oddness like this before. Sicking?
Component: General → Networking: HTTP
Product: Firefox → Core
QA Contact: general → networking.http
Version: unspecified → Trunk
Ugh, this is tricky. I believe this is due to the fact that in the classinfo for XMLHttpRequest sets the CLASSINFO_INTERFACES_ONLY flag. This is intended so that webpages can't access scriptable interfaces that aren't listed in classinfo. Unfortunately it also means that chrome can't access those interfaces either. Jst, any suggestions here?
I would love to have this bug fixed as it would solve big trouble in Firebug. Anyway, I have to remove the tee-listener from Firebug1.2 branch for now as it breaks AJAX requests. Here is a link to Firebug 1.2.0a27X XPI, if anybody would like to test/reproduce the problem. http://getfirebug.com/releases/firebug/1.2/firebug-1.2.0a27X.xpi Anyway, I am ready to assist any effort in fixing this.
Does anyone have an alternative way to obtain the source content? This looks like a dead end. Bug 430155 looks promising but not for FF3.0 and even at that it seems like its not a slam dunk.
Jonas, is this an incompatible change from past Gecko releases? /be
Brendan: No, this is how things have always worked. So I talked with jst, and came up with a sort of ugly, but possibly workable solution. However it would definitely not be something we could do for gecko1.9/firefox3. There is something called tearoff wrappers. For non-DOM objects you can do stuff like: myXPCOMObject.nsIFoo.someFunction(...) Where nsIFoo is an interface that myXPCOMObject implements. (this is obviously disabled on DOM objects). We could reuse that tearoff wrapper for this, so that when we * Are wrapping an XPCOM object in order to hand it to JS * The JS code we're about to hand the object to is chrome code * Have the CLASSINFO_INTERFACES_ONLY set on the XPCOM object we could forward the tearoff wrapper rather than the usual wrapper to the JS code. Similarly, we could do the same thing when * Script is calling .QueryInterface on an XPCOM object * The JS code we're executing is chrome code * Have the CLASSINFO_INTERFACES_ONLY set on the XPCOM object we could make QueryInterface return a tearoff wrapper rather than the normal wrapper.
Summary: nsHttpChannel::InstallCacheListener init fails OBJ_IS_NOT_GLOBAL here is not really right → Unable to wrap interface for DOM object when interface is not in classinfo (nsHttpChannel::InstallCacheListener init fails when listener is a DOM object and tee is implemented in JS)
Since Bug 430155 landed do we need this any more?
Yes. That bug added a nasty hack to work around this one; we'd like to be able to remove that hack.
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.