492534 - JS Exception fired from nsIStreamListener.onDataAvailable listener for 404 responses.

Status: RESOLVED WORKSFORME

(Core :: XPConnect, defect)

Description

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

Attachment: Test Case Extension

Firebug uses nsITraceableChannel to register a stream listener and monitor response bodies coming from the server.

Note that the registered listener must pass all callbacks to the original listener so, the chain of registered listeners is not broken. See https://developer.mozilla.org/en/NsITraceableChannel for more details.

But, the original listener fires an exception if 404 Not Found is returned, (which actually seems to be correct according to this doc: https://developer.mozilla.org/En/NsIStreamListener)

The exception can't be swallowed since it's needed by other listeners (see also: http://code.google.com/p/fbug/issues/detail?id=1712) and the problem is that it appears in Firefox Error Console and confuses users.


A simple test-extension is attached to reproduce the problem.

1) Install the attached extension and run Firefox with -console so, you can see logs within the system console (using dump)
2) Load the following page: http://www.janodvarko.cz/firebug/tests/1763/Issue1763.htm
3) The console shows the following exception:

[Exception... "Component returned failure code: 0x80540006 [nsIStreamListener.on
DataAvailable]"  nsresult: "0x80540006 ()"  location: "JS frame :: chro
me://xhrtest/content/xhrTest.js :: anonymous :: line 46"  data: no]

Thanks!
Honza

Comment 1

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

The original report is here:
http://code.google.com/p/fbug/issues/detail?id=1763

Comment 2

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

Attachment: Modified test case that shows the exception in Firefox Error Console.

I am attaching slightly better example that show the exception in Firefox Error Console:

1) Install the attached extension
2) Load the following page:
http://www.janodvarko.cz/firebug/tests/1763/Issue1763.htm
3) Open Firefox Error Console - See exceptions.

Exceptions displayed in the Error Console is what confuses users.

Honza

Comment 3

[Michal Novotny [:michal]]

It should be noted that the problem is only cosmetical because users/developers can be confused with message in error console. But it doesn't influence functionality. I'm afraid you can't pass error to the caller and suppress logging (see https://developer.mozilla.org/en/Exception_logging_in_JavaScript). Even if it were possible to suppress logging it wouldn't be good idea to do it. In your case is the error generated at http://hg.mozilla.org/mozilla-central/annotate/5a70e386a50c/modules/libpr0n/src/imgRequest.cpp#l969 and it shouldn't be probably logged. But it can be that the listener you are calling is a javascript code that is buggy and in this case the exception should be logged.

Comment 4

[John J. Barton]

This is not at all a cosmetic problem. Rather it is a functional problem. Developers fix problems in part by looking for error messages. If they see an error message they expect it to be caused by, well an error. You can see this very clearly in 
http://code.google.com/p/fbug/issues/detail?id=1879
http://code.google.com/p/fbug/issues/detail?id=1763

We need to figure out how to get this fixed.

Comment 5

[Christian :Biesinger (don't email me, ping me on IRC)]

-> xpconnect I guess?

see also bug 393627 and bug 415498

Comment 6

[Rob Campbell [:rc] (:robcee)]

interestingly, I just had one of these occur when flipping back to the Firebug Console from the HTML panel.

[Exception... "Component returned failure code: 0x80540006 [nsIStreamListener.onDataAvailable]"  nsresult: "0x80540006 (<unknown>)"  location: "JS frame :: file:///Users/rob/Library/Application%20Support/Firefox/Profiles/default.h2x/extensions/[e-mail]/components/firebug-channel-listener.js :: anonymous :: line 107"  data: no]
file:///Users/rob/Library/Application%20Support/Firefox/Profiles/default.h2x/extensions/[e-mail]/components/firebug-channel-listener.js
Line 107

if I expand the frame, I'm seeing

? in jquery.corner.js@29()jquery.corner.js (line 31)
? in jquery.corner.js@27()jquery.corner.js (line 29)
? in jquery.corner.js@1()

which are coming from a webpage (tab) I'd already closed.

Sounds like we're possibly not cleaning up our listeners properly.

Comment 7

[John J. Barton]

(In reply to comment #6)
..
> Sounds like we're possibly not cleaning up our listeners properly.

While it is possible the Firebug has some issues, this particular bug report is about a known bug in Firefox. We are not uncertain about the problem here.

Comment 8

[Rob Campbell [:rc] (:robcee)]

after looking at http://mxr.mozilla.org/mozilla-central/source/netwerk/base/public/nsIStreamListener.idl#68

it's clear that exceptions can occur and have the side-effect of canceling the original request.

I suppose the correct use of this is to wrap it in a try/catch block and do something useful or report the error if applicable. In our case, it seems to be a listener that's still hanging around after window destruction. I'm not sure that's something I want to report to end-users, but is useful for the developer.

Not sure where the best place for a fix for this is. Passing the buck to the client seems lazy and leads to lots of try code, though with networking, perhaps that's unavoidable.

After talking with Honza, we've decided to move the onDataAvailable send back into the try block and see if that solves the problem. We'd still like to see a fix for this in nsIStreamListener however.

Comment 9

[Christian :Biesinger (don't email me, ping me on IRC)]

There can't be a fix in nsIStreamListener. That interface is frozen.

So if I understand the issue correctly, what you could do is, catch the exception and cancel the channel. i.e. something like:

  try {
    listener.onDataAvailable(request, ...);
  } catch (ex) {
    request.cancel(ex.result);
  }

Comment 10

[Rob Campbell [:rc] (:robcee)]

yeah, seems so. Thanks Christian.

Comment 11

[John J. Barton]

(In reply to comment #9)
...
>   try {
>     listener.onDataAvailable(request, ...);
>   } catch (ex) {
>     request.cancel(ex.result);
>   }

But we can't pass ex.result unless we know that it is defined and is a status value. 

We should try  to analyze the exception and log information to the user on the reason for cancel.

Comment 12

[Christian :Biesinger (don't email me, ping me on IRC)]

this is a call via XPCOM, aren't all exceptions xpconnect exceptions with a defined ex.result?

Comment 13

[John J. Barton]

As I understand it, we chain a call into the onDataAvailable. So the exception can be raised by anyone on the chain correct? Or is the mechanism such that the other links always go through xpcom?

Comment 14

[Christian :Biesinger (don't email me, ping me on IRC)]

(In reply to comment #13)
> As I understand it, we chain a call into the onDataAvailable. So the exception
> can be raised by anyone on the chain correct? Or is the mechanism such that the
> other links always go through xpcom?

You get the listener to call from nsITraceableChannel, right? Then yes, it will always go through XPCOM afaik.

Comment 15

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

>   try {
>     listener.onDataAvailable(request, ...);
>   } catch (ex) {
>     request.cancel(ex.result);
>   }

Christian, can the same be done also for onStartRequest?

Honza

Comment 16

[Christian :Biesinger (don't email me, ping me on IRC)]

Yes, that will work for onStartRequest as well. If onStopRequest throws exceptions, you can just ignore them.

Comment 17

[John J. Barton]

Firebug calls cancel() now. I set the state of this bug to the closest value that makes sense.

Comment 18

[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);

Comment 19

[jack ping hua zhan]

comments #8 says 

it seems to be a listener that's still hanging around after window destruction.


When I am analyzing the content of http://www.w3schools.com/jsref/met_win_settimeout.asp
I found that the exception occurs all the time (onStartRequest exception) for this link
http://cm.g.doubleclick.net/push?client=ca-pub-1993393738408076

While this link will return 204 no content.