[
https://jira.jboss.org/jira/browse/JBSEAM-3721?page=com.atlassian.jira.pl...
]
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/69...
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