653533 - JavaScript-based channel listener (via nsITraceableChannel) causes errors to be swallowed

Status: RESOLVED WONTFIX

(Core :: XPConnect, defect)

Description

[Wladimir Palant]

Attachment: Testcase

A user complained that Adblock Plus causes errors thrown by XHR handlers to be swallowed. I traced the problem to the stream listener that Adblock Plus registers via nsITraceableChannel.newStreamListener() - it seems that having this listener immediately causes errors to be ignored. This seems to be the same issue as bug 515051, maybe bug 515051 only fixed "readystatechanged" but not "load" event?

To reproduce install the attached extension and open chrome://testextension/content/test.html. Click first button, check error console after a few seconds. Click second button, check error console again.

Expected results:
For both buttons two messages should be added to the console:
* "Page loaded, error message should follow"
* "Error!"

Actual results:
The first button only produces the first message. The error that is thrown in the "load" event handler is swallowed. This is apparently because a JavaScript-based channel listener is defined in this case.

Reproduced in Firefox 4.0 and current mozilla-central nightly on Windows 7.

Comment 1

[Boris Zbarsky [:bzbarsky]]

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.

Comment 2

[Wladimir Palant]

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.

Comment 3

[Boris Zbarsky [:bzbarsky]]

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....

Comment 4

[Wladimir Palant]

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.

Comment 5

[Loic Duros]

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,

Comment 6

[Boris Zbarsky [:bzbarsky]]

> 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.

Comment 7

[Loic Duros]

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!

Comment 8

[Loic Duros]

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.