Serious problem with IE11

[svatya]

Hi,

we are facing a pretty strange problem when running our SmartGWT aplication on IE11 (other IE versions work fine).

IE11 goes into never ending cycles when working with our SmartGWT application.
It happens very randomly and we have no steps to reproduce it. The complexity of our application makes it impossible to post a sample of the code.
Most often it happens when users work with the application, then they minimize the browser window and after some time they restore it and try to continue working.

The never ending cycle is always something like this:

onVisibilityChanged_5
$isDrawn_1
getOrCreateJsObj_2
$getOrCreateJsObj_1
create_25
doInit
getOrCreateJsObj_2
$getOrCreateJsObj_1
create_25
...

After several experiments we found a problematic place in the BaseWidget.isCreated() native method:

public native boolean isCreated()/*-{
  var id = this.@com.smartgwt.client.widgets.BaseWidget::id;
  var obj;
  return id != null && (obj = $wnd.window[id]) != null && obj !== undefined && $wnd.isc.isA.Canvas(obj) === true;
}-*/;

This method returns false for existing Canvas object.
The strange thing is that calling $wnd.isc.isA.Canvas(obj) returns true, but it is not '===' to true - last segment of the condition.

I have checked it by the following modification of the method directly in the compiled javascript:

var trueCheckCount = 0;
function $isCreated_2(this$static){
  var id = this$static.id_0, returnTemp, stackIndex;
  $stack_0[stackIndex = ++$stackDepth_0] = $isCreated_2;
  var obj;
  returnTemp = id != null && (obj = $wnd.window[id]) != null && obj !== undefined && $wnd.isc.isA.Canvas(obj) == true;

  if (returnTemp) {
    if (!(id != null && (obj = $wnd.window[id]) != null && obj !== undefined && $wnd.isc.isA.Canvas(obj) === true)) {
      alert("TRUE != TRUE  (was OK: " + trueCheckCount + "x before)");
    } else {
      trueCheckCount++;
    }
  }
  
  $stackDepth_0 = stackIndex - 1;
  return returnTemp;
}

In different test runs, the alert was shown after different number of passes. E.g. on the first run it passed 358 698 times, on the second run it passed 330 125 times …

Does anybody have any idea what could be the problem?


Svatya

Browser: IE11 (Windows7/8)
SmartGWT: v9.0p_2014-03-02/LGPL Development Only (built 2014-03-02)
GWT: 2.4

[svatya]

IE11 console screenshot

See the attached screenshot showing the problem.

[Isomorphic]

We've never seen anything like this.

For basics:

1. get the latest nightly build, or better yet move to 9.1

2. update GWT to at least 2.5

3. make sure you are using the HTML5 DOCTYPE, which is required for IE9+ (see FAQ)

Outside of that, the only cause we can think of would be if you are manually introducing multiple frames into your application, in which case, there are two window.Boolean prototypes around, and perhaps the browser is confused about 'true' from one frame vs 'true' from another.. but again that's something we've never seen before.

[svatya]

Hi,

we have contacted MS support and after some time needed for reproducing the problem, they confirmed it's a bug in IE11.
It should be fixed in IE12 and hopefully also in December IE cumulative update.

Svatya

[Isomorphic]

Thanks for letting us know. Is there a bug filed against IE11 that you can provide a link to?

[ispasov]

Hi,

we have contacted MS support and after some time needed for reproducing the problem, they confirmed it's a bug in IE11.
It should be fixed in IE12 and hopefully also in December IE cumulative update.

Svatya

Thank you very much! We have a very similar issue in IE11 with the application entering a cycle in BaseWidget.create() after long periods of use. It would be great if you can link to the official confirmation from MS!

[ispasov]

I can confirm that we are affected from the same issue in IE11. We are currently using 3.1p and the system breaks in the same way (a loop in BaseWidget:create) / See the attachmed TrueIsNotTrue.png //

We understand that this is a serious problem in the browser itself, but we are trying to find a workaround in the current situation.
An interesting note is that smartgwt 5.0 seems to be is immune or at least it takes a lot more time to hit the problem, however we are not in a position to make this upgrade soon enough :(

@Isomorphic:
* Is there going to be a patch for this? In 3.1p? In 3.1p LGPL? (yeah, I know, just had to ask!)
* Can you suggest a possible workaround that we can implement in our code?
* Can you suggest a manageable workaround that we can implement directly in the compiled javascript(in an extremely not-supported fashion)?


@svatya:
Thank you once again, great find. If you are able to share an official location for the IE issue log, that would really help us.

[Isomorphic]

We don't have a way of reproducing this, so we can't test any possible fixes.

The information you've all gathered suggests a == instead of a === might help this particular case. But we have no idea if that's a sufficient fix or where else in the code these not-quite-boolean values might pop up.

[ispasov]

We have a workaround that we don't really understand, but it does solve the immediate problem.

We defined a method that accesses the wnd object:

public static native boolean detect() /*-{
  var collisionDetect = $wnd['COLLISION_DETECTION'];
  return collisionDetect != null && collisionDetect != undefined;
}-*/;

... and we call this method every 100ms:

if (isIE11()) {
   Timer collisionDetector = new Timer() {
       @Override
       public void run() {
           detect();
       }
    };
    collisionDetector.scheduleRepeating(100);
}

We believe that the root cause is the IE11 "improved" garbage collector doing nasty stuff in the wnd namespace, and maybe the polling prevents this.

This is the only change in our code, and we are not seeing the issue anymore. If we comment the timer - we get the screenshot-ted error message (true is not true) in 20 minutes.

[Isomorphic]

Hmm, so, to put a theory behind this: GWT loads your application JavaScript in an iframe (call this the "code frame"). Your workaround code would cause the GWT code frame to constantly access the main window (which is what $wnd refers to), which might indeed prevent some kind of faulty garbage collection that IE might otherwise perform on the GWT code frame.

svatya, does this agree with whatever explanation MS gave for why this bug occurs?

Can anyone else affected by this problem confirm whether this workaround fixes their application?

[kiril_bhd]

OK. Two observations.

1) Window.alert("") and Window.confirm() are cancelling the Timer, but fortunately we cannot reproduce the problem for a long period of time, so maybe the garbage collection is not faulty triggered in this case.

2) Now the problem is when using an uploader. By opening a file selector, which is a Windows window, it stops the Timer as well, but putting the browser in a background mode, thus the faulty GC gets triggered.

We are using the gwtupload-0.6.4.jar.

Is there by any change a way to put this file selector window in a NOT MODAL state, so that maybe the Windows won't put the IE process into a background mode.

[Isomorphic]

There's no way that we know of for an ordinary web application to make the native file upload dialog non-modal.

Are you saying that when this dialog appears, the problem is *immediately* triggered?

[kiril_bhd]

The problem is not immediately triggered. It requires some system usage. But this seems to be the point where the Timer is postponed and on file selection is restored.

The problem is that there is no easy reproduction. It requires multiple attempts to break it.
But the more time is spent on the opened file chooser, the bigger the changes are for the GC to go crazy.

[svatya]

Bug fixed

Hi everybody,

MS released the fix. It's included in December Internet Explorer Cumulative Update KB3008923.

Installing this update solved our problem.

The only technical details we got was:

The bug in question is related to reclaiming of JIT functions and cross-site thunks.
A function with a cross-site thunk is getting reclaimed.
We then change the entryPoint to the InterpreterThunk, losing the cross-site thunk in the process.
Marshalling isn't done when calling this function.
In the repro in question, we end up with a Boolean True object from a different scriptContext, which doesn't match the one in the current scriptContext when comparing with ===.

[svatya]

... BTW: sorry for not replying earlier. I did not receive any information mail about new posts even I was subscribed to this thread.