[Isomorphic]

Unfortunately we've hit a hard wall here - once the parent frame has been forced into Compatibility View, there is no way to have any child frame use standards mode. Microsoft actually documents this limitation here.

And, as we cover in the FAQ, there is no way to support Compatibility View for IE9+. Microsoft has caused basic JavaScript functions (such as eval()) to leak memory and marked this a WONTFIX issue, but in Compatibility View, they also disable the HTML5 capabilities that would provide the only viable replacement.

So, there's a few ways forward:

1. find some way of moving the application out of the Compatibility View parent frame

Have a button to launch it instead, load it automatically in a new browser window, etc. Or, work to remove the requirement that the parent frame has to be in Compatibility View. We don't have the context to know what is feasible or would work best here.

2. go outside of normal Support to limp along in Compatibility View for a while

As we mentioned, because this mode is fundamentally broken, we can't accept bugs filed against it as real bugs. However, if for some reason it's acceptable in your use case for the browser to rapidly leak memory, you could open a special hourly retainer with us to fix Compatibility View issues even though this mode is not generally supported.

--

Sorry that you've ended up with this situation. While we've bent over backwards to make it so that all browser modes work in all browsers, in this particular area, Microsoft has backed everyone into a corner with a series of intersecting bugs that ultimately cannot be fully worked around.

[karankhokhani]

How to open the hourly retainer with you? Do I need to submit a request?

Another thing, we did not run into these issues in 3.0 and 3.1. So why it's an issue in 4.1?

[karankhokhani]

I have another question, the second point in your above comment says "However, if for some reason it's acceptable in your use case for the browser to rapidly leak memory, you could open a special hourly retainer with us to fix Compatibility View issues". Is this memory leak issue related to Compatibility View or to the smartgwt 4.1 version? If we downgrade to 3.1, will we still run into memory leak issue in IE10 Compat View?

[Isomorphic]

It's Compatibility View with any version of SmartGWT. In non-Compatibility View, we use HTML5 capabilities to avoid the leak. In Compatibility View, the relevant APIs are not available.

Note that this leak is *primarily* related to server contact, and we could work with you to minimize or avoid it for a particular application, but again that would be outside Support.

[karankhokhani]

Could you also please let me know why there are issues (comment 1-4) with 4.1 and did not happen with 3.0 and 3.1?

[Isomorphic]

This mode has never been supported, so what you are basically seeing is random fluctuations in an untested mode caused by fixes for actual supported modes.

If you were to test more comprehensively, you'd find things that work in 4.1 but not 3.1 - but it's random noise.

[karankhokhani]

Menu and select items are two of my major concerns. I can live with other issues.

For the menu item, I found a work around

@Override
protected void onInit()
{
super.onInit();
this.getField(0).setWidth(33);
this.getField(1).setAutoFitWidth(true);
}

Is there one for the select item scroll bar issue?

[Isomorphic]

So again, it's an unsupported mode. We can't really look into workarounds under Support, and any given workaround that works now could break at any time, even in a patch release, and this would not be considered a bug. This is why special arrangements need to be made if you need help with this mode.