[senordhuff]

I can confirm this is the build I was using when I produced the sample:

SmartClient Version: v8.2p_2012-09-16/PowerEdition Development Only (built 2012-09-16)

[Isomorphic]

OK, can you provide the error message you're seeing this time, including any line number info, and where you're seeing it?

Also, can you evaluate this JS expression using the dev console, and post the output?

isc.Class.makeEvalFrame.toString()

The output should look like:
"function isc_c_Class_makeEvalFrame ..."

[senordhuff]

That expression evals to this:

Evaluator: result of 'isc.Class.makeEvalFrame.toString()' (4ms):
"function isc_c_Class_makeEvalFrame(){this.evalFrame=isc.HiddenFrame.create({doEval:function(_1,_2){this.evalCount++;return this.getHandle().doEval(_1,_2)}});this.$104k=document.domain;this.evalFrame.draw()}"


Every DSRequest made comes back with the following response:
22:58:07.563:XRP8:WARN:RPCManager:Error evaling structured RPC response

It then outputs the entire seemingly well-formatted json response to the console as well.

And, this shows up at the end too although I suspect is a symptom of the problem above:
22:58:07.763:TMR0:WARN:Log:"Unable to get value of the property 'errors': object is null or undefined"
22:58:07.763:TMR0:WARN:Log:exception url=
22:58:07.763:TMR0:WARN:Log:"http://<domain>:8080/isomorphic/system/modules/ISC_DataBinding.js?isc_version=v8.2p_2012-09-16.js"
22:58:07.763:TMR0:WARN:Log:exception line=
22:58:07.763:TMR0:WARN:Log:1323

None of this happens when document.domain is removed. Or, when allowIE9Leak is set to true. And, none of this happens in other browsers.

[Isomorphic]

One comment on the part of the problem I am able to reproduce. The reason why this case isn't handled/expected is that you're setting the document.domain to itself--i.e. the value isn't changing. Yet IE knows that the value has been set and requires the same workarounds that we use to handle real changes. That is, at the line where you assign document.domain = "smartclientlocal.com", if you insert a console.log() right before that line, you'll see document.domain is already set to that value. So I'm not sure this is a real world use case; but, I agree it isn't being handled properly.

The case we tested was setting the domain to a shorter domain. I.e., suppose you had defined 127.0.0.1 in your hosts file as "earth.sol.milkyway.com" and then assigned it to "milkyway.com" in the example jsp. That we're able to detect and handle.

I'm currently trying to reproduce the larger issue of why you're seeing any error at all--because even with the detection issue I mention, it shouldn't be erroring out on you, but simply using the default eval (that leaks). I am not yet able to reproduce that behavior yet, but am still trying various approaches.

[senordhuff]

You mentioned that you did discover some issue with your 9/16 build. Did you make any changes so that I should pull down a new build and try this again? Either way, I'm confused why you would not be getting the same results that I am if you are following the same steps in the same version of your SDK.

[Isomorphic]

I agree it's not clear why we're seeing different behavior using the same ZIP and your sample code.

However, I've made changes to fix the issue I did see, which will be going into the SC 8.2p/SGWT 3.0p build today. Let's see if those improve your situation, and not worry further unless they don't. They should be in the next build which will happen tonight.

[senordhuff]

Success! It appears to be fixed. Thank you.

[Isomorphic]

Hi Dave
We wanted to post a follow up which relates to the IE9 leak issue (though doesn't directly impact this thread).

We have now added support for "strict" JSON formatted dataSource responses for dataSources with dataFormat set to "json" or "iscServer" via an attribute DataSource.useStrictJSON.

When this attribute is set to true, server responses will be parsed using the native JSON.parse() function where available. This means the format of the response must match the "strict JSON" format described here http://www.json.org/js.html. For standard dataSources backed by the SmartClient server and derived from a .ds.xml file, we will detect the flag on the DataSource and write out appropriately formatted responses automatically. Developers assembling their own JSON responses will of course have to match this format themselves.

Since this mechanism avoids the call to "eval()", the IE9 memory leak associated with that method is avoided.

Regards
Isomorphic Software

[senordhuff]

Thanks for letting me know. I've read that the browser native json.parse() method is often faster than eval(). Is that true and we might expect to see some performance improvement from making the switch?

[Isomorphic]

Truth be told - it's difficult to say. From our experience, the "eval" of server responses is unlikely to be a significant bottleneck in an application, and you're not particularly likely to see a user-visible impact of switching to JSON.parse() - however this may vary by data structure etc, and of course memory usage does impact performance so if you had an app that was previously leaking memory over time you may have seen it become "sluggish" once it had been left running for a long time. This should not be an issue with the native JSON.parse which avoids this leak.

One more thing to note is that JSON.parse is only available in IE9 if you specify the HTML5 doctype at the top of your application. If you do not do this, but enable strict JSON mode for your dataSource(s), we will back off to a strategy that uses eval() (but still expects strict-JSON formatted responses from the server only, and uses a different strategy to avoid leaking memory, which is only really practical with strict-formatted responses).
If you want to ensure the native JSON.parse method is available therefore (and see any performance impact associated with that), you'll need to switch to using the HTML5 doctype if you're not already.