I followed the steps to reproduce the errors but I don't see any Javascript errors in the Calendar test. I also verified, by debugging, if the new ice.ser function is invoked properly. It seems to work just fine.

First run after deleting everything (svn, intellij projects, browser cache, deployed intellij webapps), re-checking out, and re-creating all intellij dev and webapp projects. See screenshot 4. War file attached: test.war.

More problems, even after removing code related to Adnan's utilities and using ice.se() instead of ice.ser(). See screenshots 5 and 6.

In IE, JS gets executed only the first time. Calendar JS call replaced by alert() and result is still the same. See videos:

FF: http://screencast.com/t/ZjRlZTky
IE: http://screencast.com/t/ZDUzMWZhO

In the webapp at C:\svn\ossrepo\icefaces\scratchpads\sparkle\showcase\test, go to calendar page ("Calendar 4" link). Calendar is rendered by a JS call written out on the server side and executed on the client side. When you click on a checkbox (e.g. renderAsPopup), an ice.se() is called. The sever then re-writes the JS call (with different param values) and the client should then re-execute the JS. In IE the JS is executed only the first time, it never re-executes after you click on a checkbox.

The reason why the script is evaluated in FF and not IE is due to a combination between IE's specific behavior and the way JSF bridge applies updates.
When JSF bridge receives an update for a script element it just replaces the script element with the new one. FF will evaluate the code within the script element but not IE.
JSF knows about this issue and tries to make the behavior uniform for all the browsers but at the same time assumes that script elements cannot be updated because the script tag cannot have assigned an ID (as per spec: http://www.w3.org/TR/REC-html40/interact/scripts.html#h-18.2.1 ).
Any update received by JSF bridge will be stripped by the enclosed script elements, then the update is applied to the document, and finally the stripped elements are evaluated directly using eval() function.
So, to have script code evaluated properly one needs to wrap the script element with an element (such as span) that has an ID. This way the enclosing element will be updated and eventually the enclosed script will be evaluated consistently in all browsers. This strategy should be used by all components when they need to have code evaluated dynamically.

See also the attached patch for the Calendar component.

ice.se() is having problems again with <h:selectBooleanCheckbox> in IE, after updating glimmer.

<h:selectBooleanCheckbox id="renderAsPopup" value="#

" onclick="alert(this.id + ' = ' + this.checked); ice.se(event, this);"/>

It should work like this as in FF: http://screencast.com/t/ZjcwMGE3Z

But in IE, it breaks again: http://screencast.com/t/ZWE5OGFmOT

On the server side we should see a param entry like this:
calForm1:renderAsPopup = on

But there is nothing from IE, see screenshot-7.

With current Glimmer code I cannot reproduce the issue described above. Both IE6 and IE7 will send 'calForm1:renderAsPopup = on' parameter. Maybe the issue was fixed by some fixes applied to the code base in the interim.

Works in IE7 standards mode, but doesn't work in IE8 standards mode. See video at: http://screencast.com/t/MzI0Yzkx

Single submit uses a IE specific strategy for cloning the element to be submitted. It uses innerHTML and outerHTML of the element to copy the element, using Element.cloneNode does not copy also the state of the input[checkbox/radio] and select elements. IE6 and IE7 would serialize the state of the chckebox/radio properly but IE8 won't.

The fix applies a unique strategy for all browsers which moves temporarily the submitted element from its original form into the single submit form, submit the from and then put the element back. Also the state of the input[checkbox/radio] is restored programatically after the move since IE6 in this case loses the state.