diff --git a/war/src/main/webapp/scripts/hudson-behavior.js b/war/src/main/webapp/scripts/hudson-behavior.js
index c88fc9f..4eb41b7 100644
--- a/war/src/main/webapp/scripts/hudson-behavior.js
+++ b/war/src/main/webapp/scripts/hudson-behavior.js
@@ -500,7 +500,7 @@ function isInsideRemovable(e) {
  */
 function renderOnDemand(e,callback,noBehaviour) {
     if (!e || !Element.hasClassName(e,"render-on-demand")) return;
-    var proxy = geval(e.getAttribute("proxy"));
+    var proxy = eval(e.getAttribute("proxy"));
     proxy.render(function (t) {
         var contextTagName = e.parentNode.tagName;
         var c;

seems to fix it. Why is geval being used so widely?

The idea behind geval is not to let evaluated script to access local in-scope variables as well as letting them put stuff into global scope, so I think it's sound to prefer geval as much as possible.

Now, it turns out execScript always return null which means it can't be used at all where we need the return value.

The next step is, who said eval on IE is broken? On my IE8 in the standards mode, "window.eval" seems to work as expected. MSDN backs me up and claims it has been there since IE6.

Code changed in jenkins
User: Kohsuke Kawaguchi
Path:
war/src/main/webapp/scripts/hudson-behavior.js
http://jenkins-ci.org/commit/jenkins/1c578ab5542bd20904c4a5e4ebcc80b42af31bbb
Log:
[FIXED JENKINS-15617]

execScript cannot return value [1], so I'm restricting its use to where
we don't care about the return value. See ticket for more discussions

[1] http://msdn.microsoft.com/en-us/library/ie/ms536420(v=vs.85).aspx

Integrated in jenkins_main_trunk #2037
[FIXED JENKINS-15617] (Revision 1c578ab5542bd20904c4a5e4ebcc80b42af31bbb)

Result = UNSTABLE
kohsuke : 1c578ab5542bd20904c4a5e4ebcc80b42af31bbb
Files :

• war/src/main/webapp/scripts/hudson-behavior.js