[jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-3721) Seam Remoting Callback not set before server response comes back

[Shane Bryzak (JIRA)]

    [ https://jira.jboss.org/jira/browse/JBSEAM-3721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12485972#action_12485972 ] 

Shane Bryzak commented on JBSEAM-3721:
--------------------------------------

This doesn't quite make sense to me - the setTimeout() call is only being used to set onreadystatechange to an empty function, and not to set the response callback.  Take a look at the following code from remote.js (line 650 onward):

 asyncReq.onreadystatechange = function() 
  {
    if (asyncReq.readyState == 4)
    {
      var inScope = typeof(Seam) == "undefined" ? false : true;
      
      if (inScope) Seam.Remoting.hideLoadingMessage();
      
      window.setTimeout(function() {
        asyncReq.onreadystatechange = function() {};
      }, 0);
  
      if (asyncReq.status == 200)
      {
        if (inScope) Seam.Remoting.log("Response packet:\n" + asyncReq.responseText);
  
        if (callback)
        {
          // The following code deals with a Firefox security issue.  It reparses the XML
          // response if accessing the documentElement throws an exception
          try
          {         
            asyncReq.responseXML.documentElement;
            //Seam.Remoting.processResponse(asyncReq.responseXML);
	    callback(asyncReq.responseXML);
          }
          catch (ex)
          {
             try
             {
               // Try it the IE way first...
               var doc = new ActiveXObject("Microsoft.XMLDOM");
               doc.async = "false";
               doc.loadXML(asyncReq.responseText);
               callback(doc);
             }
             catch (e)
             {
               // If that fails, use standards
               var parser = new DOMParser();
               //Seam.Remoting.processResponse(parser.parseFromString(asyncReq.responseText, "text/xml"));
	       callback(parser.parseFromString(asyncReq.responseText, "text/xml")); 
             }
          } 
        }


As you can see from the above code, the setTimeout() call is only invoked after receiving a successful response.  Could you try commenting out the window.setTimeout() line from this code to see if it makes a difference?  Another option may be to move the setTimeout() code to after when the callback is invoked.

> Seam Remoting Callback not set before server response comes back
> ----------------------------------------------------------------
>
>                 Key: JBSEAM-3721
>                 URL: https://jira.jboss.org/jira/browse/JBSEAM-3721
>             Project: Seam
>          Issue Type: Bug
>          Components: Remoting
>    Affects Versions: 2.1.0.GA, 2.1.0.SP1
>         Environment: XP SP3, VMWARE 3.5i ESX, 2GB RAM, DualCore AMD 3800+
>            Reporter: Paul Chan
>            Assignee: Shane Bryzak
>         Attachments: remote.js.diff, remote.js.diff
>
>
> Original Issue
> ===========
> I tracked the issue down to one line of javascript code in remote.js
>    req.onreadystatechange = function() {};
> The following thread discusses the problem is with an old version of the JScript.dll 5.6.0.8820 which is the same version I've got on a laptop here.
>     http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/69428d48a7581567/709f621eb5a4304e?#709f621eb5a4304e
> One solution is to upgrade JScript.dll to 5.6.0.8831
>    http://www.microsoft.com/technet/security/bulletin/ms06-023.mspx
> Or we can do what they did in GWT which is to move the req.onreadystatechange out of the scope of the current function
>     window.setTimeout(function() {
>      req.onreadystatechange = function() {};
>      }, 0 );
> Problem found with the above fix
> ============================
> I have found a bug in this fix.
> If the server response comes back before the "window.setTimeout(xxx,0) expires, it will drop it.
> From reading the javascript specs, the minimum timeout value is actually around 25ms. Anything smaller than that, it gets rounded up.
> Also, using timer to set response callback are inherently flawed IMO. There's always going to be some sort of race condition.
> This problem seems to happen on internet explorer, and safari. Firebox doesn't seem to have a problem with it though.
> I discovered this problem when I set a break point on the incoming request processing code on the server. If the breakpoint is inserted, everything is good. But when I removed the breakpoint, the problem appears again.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira