Custom Query (18300 matches)


Show under each result:

Results (25 - 27 of 18300)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
Ticket Resolution Summary Owner Reporter
#15732 fixed xhr.abort gives different error messages on different browsers/ cannot use deferred since it is not published Bryan Forbes Paul Christopher


Calling response.xhr.abort from within a request.notify send callback triggers the original request's error callback. However the error message string seems to depend on the browsers being used. Firefox gives you "Cannot modify properties of a WrappedNative", Safari "INVALID_STATE_ERR: DOM Exception 11". Thus there is no simple and uniform way to treat an xhr abort in the error callback.

Resolving/ rejecting the deferred with a custom reason is not an option either: The deferred is not published with the synthetic event (The IO pipeline topics used to publish the deferred, too. Why does the new request module not publish it? Is this by design?).

Steps to reproduce the issue

Run the attached test case on different browsers. Observe the console output. The error message is different in IE, Firefox, Safari.


This is a real life example in a very reduced form. It tries to catch all ajax activities and cancel them if the session on the server has timed out. This can be easily done with the old IO pipeline topics but seems not to be possible anymore with the new request module: The request module does not publish the deferred, aborting the requests does not trigger a uniform error message.

#16239 wontfix xhr try/catch handler Bryan Forbes prashantjain68

I am new to dojo and learning dojo the hard way which is debugging the source code.

One thing I noticed: All my errors originated from the xhr class (as per the Chrome console). In one case, my xhr call succeeded but still the error handler registered with xhr was called. After debugging, I realized that my callback was being invoked in a try/ catch block in the xhr class, line 432. The callback then executed another 5000 lines of code and if there is an error in one of them, the xhr calls the error handler or reports to the browser that an error occurred in xhr line 432. I am now putting break points at different places in those 5000 lines of code to see where the error is actually happening.

This is very mis-leading and a nightmare to debug. The load and error callback registered with xhr should not be called within a try/ catch.

#18855 invalid xhr onProgress : loaded and total are null on a builded version dylan thierry.chaudy

In xhr the onProgress method call dfd.progress(response) and fill the loaded and total of the response (total only when finished)

Using Chrome, the loaded and total properties are null. (it seems working on FFox and IE)

it's working locally but not on the server with the builded version.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
Note: See TracQuery for help on using queries.