Opened 9 years ago

Closed 4 years ago

#11568 closed defect (wontfix)

[patch][ccla]XHR attribute "failOk" isn't surpressing all error messages

Reported by: James Thomas Owned by: Bryan Forbes
Priority: high Milestone: 1.11
Component: IO Version: 1.5
Keywords: xhr Cc:
Blocked By: Blocking:

Description

According to the latest API docs for dojo.xhrGet, the "failOk" attribute "indicates whether a request should be allowed to fail (and therefore no console error message in the event of a failure)"

Using the following test code.

var hostUrl = "http://localhost/a_url_to_generate_a_404";		    
var args = {failOk:false, url:hostUrl};
dojo.xhrGet(args);

I can see two error messages getting logged to the console when this request fails.

Error: Unable to load http://localhost/a_url_to_generate_a_404 status:404 Error: Unable to load http://localhost/a_url_to_generate_a_404 status:404

If I then "failOk:true" and re-issue the request, I still get one of the error messages.

Error: Unable to load http://localhost/a_url_to_generate_a_404 status:404

Looking through the code and there's a check for dfd.ioArgs.args.failOk in _deferError from xhr.js. However, the second error log is being generated in Deferred.errback in this code.

if(!error || error.log !== false){
   (dojo.config.deferredOnError || function(x){ console.error(x); })(error);
}

The Error object being generated when the xhr request fails doesn't set the appropriate error.log value to suppress the deferred error messages.

Attachments (1)

failok.patch (778 bytes) - added by Adam Peller 9 years ago.
fix from James Thomas (IBM, CCLA)

Download all attachments as: .zip

Change History (7)

Changed 9 years ago by Adam Peller

Attachment: failok.patch added

fix from James Thomas (IBM, CCLA)

comment:1 Changed 9 years ago by Adam Peller

Owner: changed from anonymous to James Burke

comment:2 Changed 9 years ago by Adam Peller

Summary: Dojo XHR attribute "failOk" isn't surpressing all error messages[patch][ccla]XHR attribute "failOk" isn't surpressing all error messages

comment:3 Changed 7 years ago by bill

Component: CoreIO
Owner: changed from James Burke to Bryan Forbes
Status: newassigned

Probably this will be fixed with dojo/request, assigning to Bryan.

comment:4 Changed 7 years ago by Ian Phillips

This still appears to be an issue with dojo.xhrPost, as of 1.7.2.

comment:5 Changed 7 years ago by waltercacau

I can confirm it is still a problem with dojo 1.7.2.

comment:6 Changed 4 years ago by dylan

Milestone: tbd1.11
Resolution: wontfix
Status: assignedclosed

This isn't relevant in the context of dojo/request, as it just provides promise callback and errback handlers rather than this sort of mechanism. Marking as wontfix.

Note: See TracTickets for help on using tickets.