IE6 Browser Crash JSCRIPT.DLL 5.6.0.8820 and HTTPRequestImpl

[Tim]

I have been suffering recently from a browser crash in IE6 on some
machines in the estate that I am deploying a GWT application to. I
have found a solution to the problem and thought that I would share it
here so that others can benefit from the (painful) investigation I
have been through.

Firstly the browser crash was determined to be related to an old
version of the JSCRIPT.DLL (IE's JavaScript interpreter) library
5.6.0.8820 as described here:

http://www.telerik.com/support/kb/article/b454K-tge-b454T-ceh-b454c-ceh.aspx

Upgrading to 5.6.0.8831 from this MS bulletin fixes the problem:

http://www.microsoft.com/technet/security/bulletin/ms06-023.mspx

The MS upgrade is the obvious solution however in my case it was not
possible to upgrade all machines in the estate or even to determine
the number of machines with the problem. As a result I had to debug
GWT and find out where the code was that triggered this JSCRIPT.DLL
flaw.

After debugging I found that the problem was caused by a GWT-RPC call;
the call succeeds but IE crashes after the load when it does some sort
of clean up. The root cause of the problem exists in the
HTTPRequestImpl class within the asyncGetImpl and asyncPostImpl
methods.

Each of these methods implement the standard Ajax onreadystatechange
callback as:

xmlHttp.onreadystatechange = function() {
if (xmlHttp.readyState == 4) {
xmlHttp.onreadystatechange =
@com.google.gwt.user.client.impl.HTTPRequestImpl::nullFunc;

handler.@com.google.gwt.user.client.ResponseTextHandler::onCompletion(Ljava/
lang/String;)(xmlHttp.responseText || "");
}
};

I found that the IE6 crash goes away if you comment out the setting of
the onreadystatechange callback to nullFunc, i.e.:

xmlHttp.onreadystatechange = function() {
if (xmlHttp.readyState == 4) {
//xmlHttp.onreadystatechange =
@com.google.gwt.user.client.impl.HTTPRequestImpl::nullFunc;

handler.@com.google.gwt.user.client.ResponseTextHandler::onCompletion(Ljava/
lang/String;)(xmlHttp.responseText || "");
}
};

It seems that the JSCRIPT.DLL flaw must be somehow related to
reassigning the callback while executing the function... who knows...
another IE flaw.

I patched the gwt-user.jar with these lines commented out, recompiled,
and the browser did not crash when performing my GWT-RPC calls,
woohoo!

I don't know the consequences of commenting out the setting of
onreadystatechange to a null function. Perhaps the GWT team can
comment and suggest whether this is necessary, does the readystate ==
4 event happen many times?

If so could the code be changed to do something like below and become
"compatible" with this IE flaw:

var handlerCalled = false;
xmlHttp.onreadystatechange = function() {
if (xmlHttp.readyState == 4) {
if (!handlerCalled) {
handlerCalled = true;

handler.@com.google.gwt.user.client.ResponseTextHandler::onCompletion(Ljava/
lang/String;)(xmlHttp.responseText || "");
}
}
};

[Peter Blazejewicz]

hi Tim,

there is a range of similar issues related to jscript.dll in IE
"browsers", see that recent post:
http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/0838d842b3f5f81b#
it links to existing ticket on issue list - which as I noted is
related to outdated .dll that can be found on some machines that are
keep un-touch as in museums,
However your finding seems interesting and can have some background
behind it. the problem is that you had used deprecated API:
HttpRequest is marked decprecated in docs (and its implementation) and
as long I'm joined group nobody cares about HttpRequest (which is good
habit) and always RequestBuilder is recommended for AJAX calls,
So if you can do the same tests using current api (ie. RequestBuilder/
Request objects) that could be better and if you succeed to replicate
issue please do not hesitate but update issue list and repost your
findings on contributors section (so before GWT 1.5 goes public
eventual fix for IE "browsers" can be applied),

regards,
Peter

On Apr 23, 8:51 pm, Tim <mr.tsm...@gmail.com> wrote:
> I have been suffering recently from a browser crash in IE6 on some
> machines in the estate that I am deploying a GWT application to. I
> have found a solution to the problem and thought that I would share it
> here so that others can benefit from the (painful) investigation I
> have been through.
>
> Firstly the browser crash was determined to be related to an old
> version of the JSCRIPT.DLL (IE's JavaScript interpreter) library
> 5.6.0.8820 as described here:
>

> http://www.telerik.com/support/kb/article/b454K-tge-b454T-ceh-b454c-c...

>
> Upgrading to 5.6.0.8831 from this MS bulletin fixes the problem:
>
> http://www.microsoft.com/technet/security/bulletin/ms06-023.mspx
>
> The MS upgrade is the obvious solution however in my case it was not
> possible to upgrade all machines in the estate or even to determine
> the number of machines with the problem. As a result I had to debug
> GWT and find out where the code was that triggered this JSCRIPT.DLL
> flaw.
>
> After debugging I found that the problem was caused by a GWT-RPC call;
> the call succeeds but IE crashes after the load when it does some sort
> of clean up. The root cause of the problem exists in the
> HTTPRequestImpl class within the asyncGetImpl and asyncPostImpl
> methods.
>
> Each of these methods implement the standard Ajax onreadystatechange
> callback as:
>
>       xmlHttp.onreadystatechange = function() {
>         if (xmlHttp.readyState == 4) {
>           xmlHttp.onreadystatechange =
> @com.google.gwt.user.client.impl.HTTPRequestImpl::nullFunc;
>

> handl...@com.google.gwt.user.client.ResponseTextHandler::onCompletion(Ljava/

> lang/String;)(xmlHttp.responseText || "");
>         }
>       };
>
> I found that the IE6 crash goes away if you comment out the setting of
> the onreadystatechange callback to nullFunc, i.e.:
>
>       xmlHttp.onreadystatechange = function() {
>         if (xmlHttp.readyState == 4) {
>           //xmlHttp.onreadystatechange =
> @com.google.gwt.user.client.impl.HTTPRequestImpl::nullFunc;
>

> handl...@com.google.gwt.user.client.ResponseTextHandler::onCompletion(Ljava/

> lang/String;)(xmlHttp.responseText || "");
>         }
>       };
>
> It seems that the JSCRIPT.DLL flaw must be somehow related to
> reassigning the callback while executing the function... who knows...
> another IE flaw.
>
> I patched the gwt-user.jar with these lines commented out, recompiled,
> and the browser did not crash when performing my GWT-RPC calls,
> woohoo!
>
> I don't know the consequences of commenting out the setting of
> onreadystatechange to a null function. Perhaps the GWT team can
> comment and suggest whether this is necessary, does the readystate ==
> 4 event happen many times?
>
> If so could the code be changed to do something like below and become
> "compatible" with this IE flaw:
>
>       var handlerCalled = false;
>       xmlHttp.onreadystatechange = function() {
>         if (xmlHttp.readyState == 4) {
>           if (!handlerCalled) {
>                 handlerCalled = true;
>

> handl...@com.google.gwt.user.client.ResponseTextHandler::onCompletion(Ljava/
> lang/String;)(xmlHttp.responseText || "");
>           }
>         }
>       };

[Tim]

Hi Peter,

I forgot to mention that I am using GWT 1.4.61. I am not using the
HTTPRequestImpl directly for AJAX calls it is called indirectly
through the generated GWT-RPC code. I was just lucky enough to find
these lines of code inside the HTTPRequestImpl.

HTTPRequest and HTTPRequestImpl are not deprecated in 1.4.61 as far as
I can see. I haven't looked at 1.5 yet but if they are replaced by
RequestBuilder and fixed in that version then great. After I get my
release out I will upgrade to 1.5, retest and post my findings.

Do you know why the 1.4.61 code is setting the
xmlHttp.onreadystatechange to nullFunc? Is it due to a memory leak or
anything as fatal?

Cheers,
Tim

On Apr 23, 8:17 pm, Peter Blazejewicz <peter.blazejew...@gmail.com>
wrote:

> hi Tim,
>
> there is a range of similar issues related to jscript.dll in IE

> "browsers", see that recent post:http://groups.google.com/group/Google-Web-Toolkit/browse_thread/threa...

[Tim]

To answer my own question, yes that bit of code is there to stop a
memory leak in IE so don't remove it.

Back to the drawing board...

[David Clément]

You can refer to the related issue:
http://code.google.com/p/google-web-toolkit/issues/detail?id=1610

And try to patch 1.4.62 with the patch here:
http://groups.google.com/group/Google-Web-Toolkit-Contributors/browse_thread/thread/6eb1d53a2dc312cb

I haven't done it on this version but on the 1.5M2 and I managed to insert the patch.

Maybe it may help you.

David

[Tim]

Thanks David I must have missed this issue somehow.

The fix certainly looks appropriate and is along the lines of what I
was thinking of implementing. I looked into the Yahoo UI connection.js
and saw that it implemented the cleanup differently. If the
setTimeout() approach works then it is much simpler.

I will give it a try and post back if my issue is fixed.

Cheers,
Tim

On Apr 26, 7:45 pm, "David Clément" <dav.clem...@gmail.com> wrote:
> You can refer to the related issue:http://code.google.com/p/google-web-toolkit/issues/detail?id=1610
>

> And try to patch 1.4.62 with the patch here:http://groups.google.com/group/Google-Web-Toolkit-Contributors/browse...

>
> I haven't done it on this version but on the 1.5M2 and I managed to insert
> the patch.
>
> Maybe it may help you.
>
> David
>

> On Wed, Apr 23, 2008 at 8:51 PM, Tim <mr.tsm...@gmail.com> wrote:
>
> > I have been suffering recently from a browser crash in IE6 on some
> > machines in the estate that I am deploying a GWT application to. I
> > have found a solution to the problem and thought that I would share it
> > here so that others can benefit from the (painful) investigation I
> > have been through.
>
> > Firstly the browser crash was determined to be related to an old
> > version of the JSCRIPT.DLL (IE's JavaScript interpreter) library
> > 5.6.0.8820 as described here:
>

> >http://www.telerik.com/support/kb/article/b454K-tge-b454T-ceh-b454c-c...

>
> > Upgrading to 5.6.0.8831 from this MS bulletin fixes the problem:
>
> >http://www.microsoft.com/technet/security/bulletin/ms06-023.mspx
>
> > The MS upgrade is the obvious solution however in my case it was not
> > possible to upgrade all machines in the estate or even to determine
> > the number of machines with the problem. As a result I had to debug
> > GWT and find out where the code was that triggered this JSCRIPT.DLL
> > flaw.
>
> > After debugging I found that the problem was caused by a GWT-RPC call;
> > the call succeeds but IE crashes after the load when it does some sort
> > of clean up. The root cause of the problem exists in the
> > HTTPRequestImpl class within the asyncGetImpl and asyncPostImpl
> > methods.
>
> > Each of these methods implement the standard Ajax onreadystatechange
> > callback as:
>
> > xmlHttp.onreadystatechange = function() {
> > if (xmlHttp.readyState == 4) {
> > xmlHttp.onreadystatechange =
> > @com.google.gwt.user.client.impl.HTTPRequestImpl::nullFunc;
>

> > handl...@com.google.gwt.user.client.ResponseTextHandler

> > ::onCompletion(Ljava/
> > lang/String;)(xmlHttp.responseText || "");
> > }
> > };
>
> > I found that the IE6 crash goes away if you comment out the setting of
> > the onreadystatechange callback to nullFunc, i.e.:
>
> > xmlHttp.onreadystatechange = function() {
> > if (xmlHttp.readyState == 4) {
> > //xmlHttp.onreadystatechange =
> > @com.google.gwt.user.client.impl.HTTPRequestImpl::nullFunc;
>

> > handl...@com.google.gwt.user.client.ResponseTextHandler

> > ::onCompletion(Ljava/
> > lang/String;)(xmlHttp.responseText || "");
> > }
> > };
>
> > It seems that the JSCRIPT.DLL flaw must be somehow related to
> > reassigning the callback while executing the function... who knows...
> > another IE flaw.
>
> > I patched the gwt-user.jar with these lines commented out, recompiled,
> > and the browser did not crash when performing my GWT-RPC calls,
> > woohoo!
>
> > I don't know the consequences of commenting out the setting of
> > onreadystatechange to a null function. Perhaps the GWT team can
> > comment and suggest whether this is necessary, does the readystate ==
> > 4 event happen many times?
>
> > If so could the code be changed to do something like below and become
> > "compatible" with this IE flaw:
>
> > var handlerCalled = false;
> > xmlHttp.onreadystatechange = function() {
> > if (xmlHttp.readyState == 4) {
> > if (!handlerCalled) {
> > handlerCalled = true;
>

[Tim]

I can confirm that the issue 1610 patch applied to 1.4.61 fixes my
problem.