jsdo synchronous xmlhttprequest - Forum - Mobile - Progress Community

jsdo synchronous xmlhttprequest


jsdo synchronous xmlhttprequest

  • progress.jsdo.3.1.js

    Saw a warning in firefox about this referring to https://xhr.spec.whatwg.org/.

    Regards, Stefan.

  • Stefan,
    The progress.data.Session object in the JSDO library that has been used for login(), addCatalog(), and logout() has both synchronous and asynchronous versions of those calls. The Mobile App Builder express projects use the synchronous versions, so you are likely to see a warning about that in the debug console if you are using the MAB.  
    As of the 4.0 version of the JSDO, there is a new object for doing session management, progress.data.JSDOSession. Its implementations of login, addCatalog, and logout are async only. (The older Session object is also still available, but we recommend using the JSDOSession object.)
    The Progress Data Service template that is available in Telerik Platform and at GitHub uses the JSDOSession object.
    From: agent_008_nl [mailto:bounce-agent_008_nl@community.progress.com]
    Sent: Thursday, July 30, 2015 8:02 AM
    To: TU.Mobile@community.progress.com
    Subject: [Technical Users - Mobile] jsdo synchronous xmlhttprequest
    Thread created by agent_008_nl


    Saw a warning in firefox about this referring to https://xhr.spec.whatwg.org/.

    Regards, Stefan.

    Stop receiving emails on this subject.

    Flag this post as spam/abuse.

  • Merci Wayne,

    I'll upgrade.

    Regards, Stefan.

  • Just downloaded 4.0 but the warning still comes up (I checked the cache refresh). It comes from progress.jsdo.js:  xhr.open(verb, uri, async);

    Regards, Stefan.

  • Hello Stefan,

    As Wayne mentioned, you would need to use the asynchronous version of login(), addCatalog() and logout().

    Here is a link to an example using the new progress.data.JSDOSession object with promises:


    You can download this and other examples from the following link:


    Best regards.

  • Thanks Edsel,

    I did not find the progress.data.JSDOSession object, should that replace progress.jsdo.js version 4.0? Where can I download it? I did not see it on github.com/.../JSDO.

    Regards, Stefan.

  • Hello Stefan,

    What file are you using?

    I just took a look and confirmed that the progress.data.JSDOSession object is present in the progress.jsdo.js from github.com/.../lib.

    Please check.



  • Edsel,

    I was looking for an object with the exact name you provided,  progress.data.JSDOSession. You must mean progress.jsdo.js, that file I can see on the link you give,

    I downloaded the zip from github.

    Regards, Stefan.

  • Yes, progress.jsdo.js is the file that contains the progress.data.JSDOSession object.

    (progress.all.js is progress.jsdo.js + progress.data.kendo.js which is the file containing the support for the Kendo UI DataSource.)

    Please let me know if you need additional information.


  • Hi Edsel,

    I do not need info, only wanted to point out that I still see the warning in firefox devtools (see somewhere above) about the synchronous xmlhttprequest. It shows up on a custom read operation.

    Regards, Stefan.

  • Hello Stefan,

    Thank you for the feedback.

    I would like some additional information on what you are seeing.

    Your reference to "custom read operation" make it sounds like you are seeing the issue with an invoke operation.

    Invoke operations are asynchronous by default (there is a parameter that you could use if you really wanted to call them synchronously).

    BTW, I tested with program example004.html using Firefox devtools:


    This program shows the warning and points to line number 8954.

    This line corresponds to function setXHRCredentials() which is called from login().

    Once I changed the code to use the new progress.data.JSDOSession object which uses Promises, the warning is no longer shown. See the execution with the updated version example004p.html:


    Are you using the new JSDOSession object?

    Could you check the line number of code that causes the message?



  • I'll let you know after the weekend. I'll add a debug message also to the jsdo.

  • Ah, now I understand Wayne's message. Reading documentation.progress.com/.../oemobile1151

    I'm changing my code according to this.

    Thanks, Stefan.

  • After close reading the code (see below for a copy) in the mentioned documentation link I do not understand which problem it solves compared to the code in the old progress.data.session. In fact the execution of the calls is still synchronous. At first after the catalog json has been loaded from the webserver you can start loading a first page of data. I don't know what happens with the GET of home.html, in the old progress.data.session it was fetched even three times synchronously from the webserver after navigating to the URL. I'm trying to solve the same problem for the extra data I need when fetching a first page of data (I need to fetch a dataset with - for now, more to follow -  validations). See community.progress.com/.../16826.aspx last message.

    Ideal for UX would be *only one* roundtrip after navigating to a URL. And why shouldn't this be doable.






    Again something for the DRS (dark room sessions) aka the CCS?

    Regards, Stefan.

    var session;

    /* create jsdoSession   */

    session = new progress.data.JSDOSession(

           { serviceURI: "http://localhost/CustService",

             authenticationModel: progress.data.Session.AUTH_TYPE_FORM


    /* create login screen (using UI defined in HTML file) */

    window.loginView = kendo.observable( {

       submit: function() {

           var loginParams = {

                    username: this.username,

                    password: this.password) };

           /* log in (also loads CustService.json if it succeeds) */


               ).done( // Logged in

               function(session, result, info) {


                       ).done( // JSDO catalog loaded

                       function(session, result, details){

                           /* success function – create grid and datasource */

                           $("#grid").kendoGrid( {

                               dataSource: {

                                   type: "jsdo",

                                   transport: {

                                       jsdo: { resourceName: "Customer" }


                                   error: function(e) {

                                       console.log("Error: ", e);



                               /* etc., other kendoGrid properties */


                           /* switch UI to show grid */

                           window.location.href = "#grid";

                       }).fail( // JSDO catalog not loaded

                       function(session, result, details){

                           alert("JSDO catalog failed to load");

                   }); //JSDOSession addCatalog()

               }).fail( // Not logged in

               function(session, result, info) {

                   /* display error message, stay on login screen */

                   alert("Login failed");

           }); // JSDOSession login()

       } // observable submit method

    } ); // kendo.observable

  • You're correct that, from the standpoint of the app developer, async login() and addCatalog() calls need to be done sequentially anyway, since you usually don't want to try to access the catalog until you have successfully logged in, and you definitely don't want to try to create a JSDO until you have retrieved the appropriate catalog. (In fact, that is why the initial implementations of login() and addCatalog() were synchronous.) However, synchronous HTTP requests are, in general, deprecated, and in fact we had a bug where the synchronous login() method did not work in Firefox in certain situations because of Firefox's restrictions on synchronous requests. Other user agents are more lenient, but will still give you warnings about making synchronous requests.

    The async login and addCatalog also give the app the opportunity to do something else while waiting for the reply (although I'll admit that there usually won't be a long wait anyway).