Raise your hand if you've formatted a two-option field on a Dynamics CRM entity form as a checkbox. Keep it raised if you've implemented client-side form logic triggered by changes to that field. Now, start waving your hand wildly if you've overridden the onclick event to invoke your logic immediately rather than wait for control focus to change. If, like me, you're starting to attract attention, keep reading (and please, put your arm down).
Adding client-side event handlers to the onclick event of checkbox controls on entity forms is an unsupported customization that has been perpetrated across many versions of Dynamics CRM. The technique serves as a workaround to the native onchange event behavior of the two-option (Boolean) field when rendered as a checkbox control. Native behavior dictates that handler(s) are not fired until after the control loses focus. This behavior can create an odd user experience when onchange logic should be invoked directly after the user action (i.e. conditionally display/enable a related form control). The only alternative to the unsupported workaround is to render the field as a radio button control which may not provide the desired user experience.
Until recently, I identified this unsupported customization in Code Review reports, but lowered the severity based on risk level and the lack of supported alternatives. That is until I discovered a minor change in Update Rollup 12. As of the UR12 release, the two-option (Boolean) field's onchange event now occurs immediately when formatted as a checkbox control. Say what!?! This is a change that I (and many others) have been advocating for years. Like me, you may have initially overlooked it in the SDK release notes (V5.0.15) because it's only referenced as a general documentation update to the onchange event. Either way, I'll take it. One caveat: the behavior isn't supported by Internet Explorer 7 or 8. For these versions, the control reverts to prior behavior based on focus change.
Don't believe me? Read about it here. Celebrate briefly (quietly). Update CRM to UR12 (or later). Upgrade your browser to IE9 (or later). Finally, clean up your script libraries that register handlers with CRM field onclick events. As for me, gone are the days of sugar coating the severity of this violation in future Code Review reports. No excuses, no exceptions!
Microsoft Premier Field Engineer
Can you explain me why this behaviour isn't supported by IE <9? If the client's browser version is not in my control, what is the best way to have consistent behaviour across browsers?
@boriscallens: I appreciate your situation and concern for a consistent user experience. I'm not privy to the rationale for only supporting IE9+ with this change. I can say that to even benefit from this change, the CRM environment would require either CRM Online with the December 2012 Service Update or Update Rollup 12 for on-premise. Both of these updates drop support for IE7 in order to take advantage of the new cross-browser compatibility feature (support.microsoft.com/.../2784954). Thus, the issue you present is isolated to IE8. While that may seem to be a limitation, consider that support has been added for Safari, FireFox, and Chrome browsers. Your options are A) keep your environment patched to a pre-UR12 build and maintain prior onchange behavior, B) proceed with UR12 and select the system setting option to use pre-UR12 forms (with HTC support), or C) proceed with UR12 and establish minimum supported browser(s)/version(s) for your user base. I would highly recommend the latter, primarily for client-side performance reasons. Hope that helps!