Closed Bug 653533 Opened 9 years ago Closed 9 years ago
Script-based channel listener (via ns ITraceable Channel) causes errors to be swallowed
Bug 515051 was "fixed" by not using a JS-implemented nsIStreamListener in Firebug as the argument to setNewListener and using a stream listener tee instead. Since they just wanted to snoop, not modify, this worked.
Ouch... I guess that in my case nsIStreamListenerTee would only create unnecessary overhead by duplicating all the data - I don't care about the data (yet), I only want to know when it is done.
And in particular, there is no good solution for this on the platform side for the reasons described in bug 515051, short of giving you a way to register just a request observer tee....
Anyway, I've given up on the attempts to clean up the data attached to the channel: https://hg.adblockplus.org/adblockplus/rev/76413c22b15e WONTFIX I guess.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
Hello, I am working on a Firefox add-on which intercepts http responses and modifies those that are of type text/html them before they get parsed by Firefox. To do this I have somewhat followed the following blog post: http://www.softwareishard.com/blog/firebug/nsitraceablechannel-intercept-http-traffic/ However, onDataAvailable, I do not have the following line: this.originalListener.onDataAvailable(request, context, inputStream, offset, count); Instead I've placed this line in "onStopRequest", and I use a concatenated string of all the bits gathered from onDataAvailable. However, it seems that sometimes onStopRequest is completely bypassed and none of the logic I have inside of it gets executed at all. I see that onDataAvailable is triggered, often many times, but then onStopRequest isn't. It does not happen every time, far from it, and it seems to occur more often on certain pages or website, that is the case, I found, with the product detail pages on Amazon, such as: http://amzn.to/vT22FB Here is the original file: https://gitorious.org/librejs/librejs/blobs/master/lib/http_observer/http_request_observer.js#line92 You can see the first chunk is "onDataAvailable", and instead of passing the chunk of data back to the original listen, it pushes it in an array to be concatenated when "onStopRequest" gets triggered. If I place a console.log('onStopRequest triggered'); at the very top of onStopRequest, I'll see it most of the time, however from time to time (with cache cleared everytime) I won't see it, and none of the code in onStopRequest is triggered. That's quite a problem since my add-on needs to modify the response at that time. I also don't understand why the page would still load even though the data isn't passed to the original listener from onDataAvailable. Is the problem I'm describing similar to this bug that won't be fixed? I see in the adblockplus diff file that the chunk with onStopRequest was removed. Thanks for your help,
> Is the problem I'm describing similar to this bug that won't be fixed? No. If you're not getting an onStopRequest, then something is _seriously_ broken. Necko guarantees that it will deliver onStopRequest. > I also don't understand why the page would still load even though the data isn't passed > to the original listener from onDataAvailable. It wouldn't, if you're actually intercepting the respose involved.
Hi Boris, Thanks much for your answer. The issue I described is totally unrelated to onStopData; it is due to the fact that I'm using an iframe to sandbox the html page, and the Amazon full product pages actually don't have a doctype and thus are rendered in quirks mode. Thanks again for your help!
As it turns out, the response not being caught was due to a conditional, I was checking for: request.contentType === 'text/html'. In the case of Amazon, from time to time, the contentType will be undefined.
You need to log in before you can comment on or make changes to this bug.