WebConsole: Error in RL_onDataAvailable NS_BINDING_ABORTED

RESOLVED FIXED in Firefox 4.0b7

Status

defect
RESOLVED FIXED
9 years ago
Last year

People

(Reporter: julian.viereck, Assigned: ddahl)

Tracking

Trunk
Firefox 4.0b7
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [kd4b6])

Attachments

(1 attachment)

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.
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.
(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?
I think that bug 492534 could be related. Firebug is catching exceptions fired from the original listener and calling cancel on the request.

Honza
(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!)
Assignee: nobody → ddahl
Whiteboard: [kd4b6]
Posted patch Patch v1.0Splinter Review
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 :/
Attachment #470871 - Flags: feedback?(ddahl)
Attachment #470871 - Flags: feedback?(ddahl) → feedback+
(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.
Attachment #470871 - Flags: review?(sdwilsh)
Comment on attachment 470871 [details] [diff] [review]
Patch v1.0

r+a=sdwilsh
Attachment #470871 - Flags: review?(sdwilsh)
Attachment #470871 - Flags: review+
Attachment #470871 - Flags: approval2.0+
Keywords: checkin-needed
http://hg.mozilla.org/mozilla-central/rev/b07129306dc1
Status: NEW → RESOLVED
Closed: 9 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 4.0b6
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);
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.