JavaScript: How to simulate change event in internet explorer (delegation)

While I agree that it would be better having only one event listener on the whole form instead of many listeners, one for each element, you have to evaluate the costs and benefits of your decision. The benefit of one listener is a reduced memory footprint. The downside is that you have to do such complex code tricks to get around one browser's incorrect implementation of events, increasing the execution time, misusing event types, registering and unregistering event listeners repeatedly, maybe causing confusion to some users.

Coming back to the benefit, the memory footprint isn't so big if you just attach the same function as a listener for all the elements. And memory is something that current computers don't lack.

Even if this doesn't answer your question, I'd advise you to stop trying to make this work, and instead attach listeners on each form element.

To address your points a bit:

  1. Are you sure about that? I've tried the basic example from Microsoft's documentation, and both IE7 and IE8 fire the onchange listener after I click on an option from the dropdown. It even fires when changing the selection with the up/down keys.

  2. While it's true that you can't easily connect an event on a label to the affected checkbox, why would you want to do that? The change event will be triggered on the checkbox anyway, and you should only care about that one. However, if you must get to the checkbox from an event on a label, then you could do that manually. If the event targets a label, then you know that the label is somehow related to an input. Depending on how you use labels, you could either select the input element nested inside the label, or get the element with the ID found in the for attribute of the label.

  3. One way of fixing the checkboxes return the previous value on change bug is to do a this.blur() on focus events on checkboxes.

  4. When you say "handler", you mean the onfocusin event handler, or the changeDelegator? It is normal to see a focusin event fire when reactivating a tab. I don't know for sure why the event is fired more than once, so I'm just guessing: one might be the focus that the active input receives; the second might be the focus that the document itself receives; I have no idea why a third call happens. I don't understand what do you mean by "if the checked state actually changed, [...] if I clicked the checkbox directly only once".


Well, I had another crack at it, and I've come up with a fairly decent approach (at work it did the trick - I've tried to replicate the code I wrote but after a few beers it might contain some errors but the spirit remains the same)

window.attachEvent('onload',function ieLoad()
{
    var mainDiv = document.getElementById('main');//main div, from here events will be delegated
    var checks = mainDiv.getElementsByTagName('input');//node list of all inputs
    var checkStates = {};
    for (var i=0;i<checks.length;i++)
    {
        if (checks[i].type === 'checkbox')
        {//get their checked states on load, this object serves as a reference
            checkStates[checks[i].id] = checks[i].checked;
        }
    }
    mainDiv.attachEvent('onfocusin',(function(initState)
    {//initState holds a reference to the checkStates object
        return function(e)
        {
            e = e || window.event;
            var target = e.target || e.srcElement;
            //id of checkboxes used as key, so no checking for tagName or type required
            if (!initState.hasOwnProperty(target.id) || target.checked === initState[target.id])
            {//don't call method if checkstate is unchanged, either. I'll explain in a minute
                return e;
            }
            initState[target.id] = target.checked;//set new checked-state
            changeDelegator.apply(target,[e]);//delegate
        };
    })(checkStates));
    window.detachEvent('onload',ieLoad);//avoid mem-leak with onload handler!
});

I've found out that the focusin events fire twice in some cases for radio's and checkboxes. Using an object that holds the actual checked states of all checkboxes is less expensive than individual handlers, and it allows me to only delegate the event after the value of the element has changed.

The changeDelegator function is only called when needed, but the anon function that I posted here still gets called Waaaay more than I wanted it, but this approach still outperforms the individual handlers-take.

I left out the selects, but I got them working, too (similar take, in the full version of my code the closure has 2 objects, and I made it, so I can flag an id, fire the blur event when needed, and the client is redirected).
At the end of the run, even though I've learned some new tricks, the main thing I take away from this exercise is an even more profound hatred of that ghastly, gritty golem of a thing called IE... But if anybody else might ever want to delegate change events in IE, know that it is (almost) possible