592264 - WebConsole: Error in RL_onDataAvailable NS_BINDING_ABORTED

Status: RESOLVED FIXED

(DevTools :: General, defect)

Description

[Julian Viereck]

Serving some pages with an opened Error Console I've noticed to get this error message:

Error: [Exception... "Component returned failure code: 0x804b0002 (NS_BINDING_ABORTED) [nsIStreamListener.onDataAvailable]"  nsresult: "0x804b0002 (NS_BINDING_ABORTED)"  location: "JS frame :: resource://gre/modules/HUDService.jsm :: RL_onDataAvailable :: line 206"  data: no]
Source File: resource://gre/modules/HUDService.jsm
Line: 206

The error points to this: http://mxr.mozilla.org/mozilla-central/source/toolkit/components/console/hudservice/HUDService.jsm#206

I tried to look up in which cases the NS_BINDING_ABORTED is thrown, but there is no documentation about nsIStorageStream on the MDC :/


Here's the request header as copied from Firebug for one request that I could identify to cause this error:

GET /asis/mediacom.de.asis HTTP/1.1
Host: www.strato.de
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b5pre) Gecko/20100829 Firefox/4.0b5pre
Accept: image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://www.heise.de/
Cookie: VIEW=MEDIACOM


And the response header:

HTTP/1.1 200 OK
Date: Tue, 31 Aug 2010 14:53:01 GMT
Server: Apache/1.3.33 (Unix) mod_perl/1.29 mod_ssl/2.8.22 OpenSSL/0.9.7d
P3P: CP="ALL CUR DEV PSA OUR IND STA"
Set-Cookie: VIEW=MEDIACOM; domain=.strato.de; path=/; expires=Wed, 01-Sep-2010 00:00:00 GMT
Keep-Alive: timeout=4, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/plain
Content-Language: de

The response body is empty.

Comment 1

[David Dahl :ddahl]

the nsIStorageStream idl is here; http://mxr.mozilla.org/mozilla-central/source/xpcom/io/nsIStorageStream.idl

Comment 2

[Shawn Wilsher :sdwilsh]

Pretty sure that this has nothing to do with the storage stream here.  This is very likely the original listener throwing NS_BINDING_ABORTED to stop the load.

This error isn't actually an error in that case.  I think we can put a try around the calls to the original listener, and then throw the exception in order to make the console noise go away.

Comment 3

[Shawn Wilsher :sdwilsh]

(In reply to comment #2)
> This error isn't actually an error in that case.  I think we can put a try
> around the calls to the original listener, and then throw the exception in
> order to make the console noise go away.
Of course, XPConnect is going to show that anyway.  Not sure we can get around this, unless we want to call cancel on the request?

Comment 4

[Jan Honza Odvarko [:Honza] (always need-info? me)]

I think that bug 492534 could be related. Firebug is catching exceptions fired from the original listener and calling cancel on the request.

Honza

Comment 5

[Shawn Wilsher :sdwilsh]

(In reply to comment #4)
> I think that bug 492534 could be related. Firebug is catching exceptions fired
> from the original listener and calling cancel on the request.
Oh neat, bug 492534 comment 9 says the same thing I said in comment 3 (but with authority!)

Comment 6

[Julian Viereck]

Attachment: Patch v1.0

Calls aRequest.cancle() if something goes wrong when propagating the onDataAvailable or onStartRequest data.

This patch has no unit tests. I'm not really sure how to test this :/

Comment 7

[Shawn Wilsher :sdwilsh]

(In reply to comment #6)
> This patch has no unit tests. I'm not really sure how to test this :/
It's not worth it for this patch, so I wouldn't worry about it.

Comment 8

[Shawn Wilsher :sdwilsh]

Comment on attachment 470871 [details] [diff] [review]
Patch v1.0

r+a=sdwilsh

Comment 9

[David Dahl :ddahl]

http://hg.mozilla.org/mozilla-central/rev/b07129306dc1

Comment 10

[jack ping hua zhan]

What is the reason for the exception NS_BINDING_ABORTED to be thrown?
Seems to me, it is not come from the uncertainty of the network, but the design, so the above mentioned "fix" is just to circumvent the problem, rather than a truly fixation.

A truly fixation should be based on the reason why NS_BINDING_ABORTED was thrown. I guess, the timing of the call to these functions might be so late that some objects have already become invalidated.
originalListener.onStartRequest(request, context);
originalListener.onStopRequest(request, context, statusCode);
originalListener.onDataAvailable(request, context, is, offset, count);