Just an FYI. Previously, in Mojarra, the default ajax behavior for components that rendered radio and checkbox was onchange. Unfortunately, this doesn't work in the way any user would expect in IE - the onchange event will not fire until the component loses focus. This makes it pretty much useless, as a user will click on a radio button then wonder why nothing is happening. Note that all other browsers fire the onchange event when you'd expect - without waiting for a blur event first. So, in the interests of making all browsers behave similarly, I've changed the default behavior to onclick for those components. Now, when you click on a radio or checkbox, the event will fire immediately. Sadly, this means that we'll now also fire events even when the value isn't changed (such as clicking multiple times on the same radio button). In general, most application developers shouldn't notice the difference, but it's conceivable that it might trip someone up at some point. The alternative, adding an onclick="this.blur();", seemed more likely to add problems than a simple change from onchange to onclick. Just wanted to let you know where we stood with this. As always, comments appreciated. Jim

Yep. I believe that both Trinidad and ADF Faces use this workaround. > Sadly, this means that we'll now also fire events even when the value > isn't changed (such as clicking multiple times on the same radio > button). I see this behavior in both the Trinidad and ADF Faces demos. FWIW, this is one of the main reasons why we introduced the logical "valueChange" (and "action") client event names: we wanted to abstract page authors away from details of the implementation-specific dom events. Rather than having to worry about whether the component's value happens to change in response to click/blur/change events (or some combination of these), the page author simply asks to be notified when the component's value has changed.

Martin Marinschek wrote: > Hi Jim, > > that is a well-known bug of IE - no way around this. AFAIK, all > component libraries with AJAX support do it exactly the same way - use > onclick for radios and checkboxes. > > regards, > > Martin > > On 8/12/09, Jim Driscoll <Jim.Driscoll(a)sun.com&gt; wrote: >> Just an FYI. >> >> Previously, in Mojarra, the default ajax behavior for components that >> rendered radio and checkbox was onchange. >> >> Unfortunately, this doesn't work in the way any user would expect in IE >> - the onchange event will not fire until the component loses focus. >> This makes it pretty much useless, as a user will click on a radio >> button then wonder why nothing is happening. Note that all other >> browsers fire the onchange event when you'd expect - without waiting for >> a blur event first. >> >> So, in the interests of making all browsers behave similarly, I've >> changed the default behavior to onclick for those components. Now, when >> you click on a radio or checkbox, the event will fire immediately. >> Sadly, this means that we'll now also fire events even when the value >> isn't changed (such as clicking multiple times on the same radio >> button). In general, most application developers shouldn't notice the >> difference, but it's conceivable that it might trip someone up at some >> point. The alternative, adding an onclick="this.blur();", seemed more >> likely to add problems than a simple change from onchange to onclick. >> >> Just wanted to let you know where we stood with this. As always, >> comments appreciated. >> >> Jim >> >> > >

Just an FYI. Previously, in Mojarra, the default ajax behavior for components that rendered radio and checkbox was onchange. Unfortunately, this doesn't work in the way any user would expect in IE - the onchange event will not fire until the component loses focus. This makes it pretty much useless, as a user will click on a radio button then wonder why nothing is happening. Note that all other browsers fire the onchange event when you'd expect - without waiting for a blur event first. So, in the interests of making all browsers behave similarly, I've changed the default behavior to onclick for those components. Now, when you click on a radio or checkbox, the event will fire immediately. Sadly, this means that we'll now also fire events even when the value isn't changed (such as clicking multiple times on the same radio button). In general, most application developers shouldn't notice the difference, but it's conceivable that it might trip someone up at some point. The alternative, adding an onclick="this.blur();", seemed more likely to add problems than a simple change from onchange to onclick. Just wanted to let you know where we stood with this. As always, comments appreciated. Jim