Maybe we don't need to dynamically instrument document.write-generated code if we implement instrumentation in JavaScript.

A proxy can turn a chunk of script code into a giant
var scriptCode = "...the original code here...";
scriptCode = instrument(scriptCode)

This way we can get to all document.write, innerHTML, etc at the time of instrumentation and turn all
document.write("<div id='test'>TEST</div>")
document.write(instrumentHTML("<div id='test'>TEST</div>"))

We will need some HTML processing on the proxy(server-side) too. I am not sure how we can use the same instrumentHTML implementation on both the server and the client. The only solution that comes to mind is use the JavaScript interpreter in the browser and JScript or JScript.Net on the server.

That still leaves the question of how we can parse the JavaScript code in order to instrument it.


On 8/25/07, Matthias Miller <> wrote:
Microsoft Research has released an interesting project that uses code
instrumentation to add profiling support to JavaScript. Their web site
links to a paper that describes a way to detect cycles using code

This could be a much more thorough and robust way to detect cycles,
since you could rewrite the code shove all local variables into a
"scope" object. This "scope" object could be stored on the function
itself and could be used to detect cycles. For example, this code:

    function show(startNum) {
        var div = document.createElement('DIV');
        var i = startNum;
        div.onclick = function() { alert(i++); };

would be turned into something like:

    function show(startNum) {
        // TODO: inherit parent scope to support closures within closures.
        var __scope = { startNum: startNum }; // copy parameters into
    local scope
        __scope.div = document.createElement('DIV');
        __scope.i = __scope.startNum;
        __scope.div.onclick = function() { alert(__scope.i++); };

Further, the "__scope" object would automatically be associated with the

        __scope.div.onclick.__parentScope = __scope;

This same kind of code instrumentation can be used to add diagnostic
information to createElement calls, etc. to track where they were created.

It seems to me this is the only way to bust through some of the current
limitations. Most of the code could be instrumented via a proxy, in the
same way that Ajax View instruments the code. However, all code
generated by "document.write", "eval", "innerHTML",
"createElement('SCRIPT')", etc. would need to be instrumented
dynamically. This could perhaps be done by a synchronous XHR to the server.



This email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>
Ieleak-devel mailing list