UPDATE: we're using 2009 2 IG package, for example (web.config snippet): Infragistics35.WebUI.UltraWebGrid.v9.2, Version=9.2.20092.2137
We've started testing our application with IE9 (RC). It seems that there's a JavaScript error rising from IG's components:
As you can see, the problem is from the following code:
if (document.implementation && document.implementation.createDocument){ igtbl_XSLTProcessor.prototype.__defineGetter__("output", function _igtbl_XSLTProcOutput() {<snip>
When switching to compatibility view (IE7/8), it works ok.
After debugging a little, it seems like the code "document.implementation.createDocument" (see above) was probably meant to filter out IE and to run on mozilla only. However, in IE9 'createDocument' isn't 'undefined', and the next line of code breaks, as "__defineGetter__" is mozilla-only and isn't supported in IE browsers.
Naturally, I'd hate to tell our customers that our recently released web application breaks on the latest IE browser and that they'll have to use Compatibility View.
Please advise A.S.A.P.
I have the same issues with IE9.
This can be fixed by placing the following meta tag in the <head/>, which tells IE9 to mimic IE8.
<meta http-equiv="X-UA-Compatible" content="IE=8" />
No need to use Compatibility Mode.
I am hoping IG comes out with IE9 compatibility soon. It has been in beta going on ages. It seems odd to wait until go live.
Hi Rob,
Thanks for your reply.
While placing a meta tag to switch to Compatibility View is a possible workaround (although not always working, at least not in IE8), it is hardly an acceptable solution, as it deprives us developers and customers alike from a good, fast and newer engine to run our web applications, and forces us to sticking with older broken browser engines.
I believe that IG should provide a reasonable solution without having us to upgrade to their latest controls, just because several 'if' code statements break now, and without compromising on older browser engines.
UPDATE: The META tag didn't solve the problem. As in IE8, the browser ignored it and continued to run in IE9 mode.
I agree that it is not an adequate solution.
On a different thread, Infragistics stated that they would be working on IE9 compatibility *after* IE9 is released. While that might save them in some development cost (not having to accommodate last-minute changes), it seems like a bass ackwards decision for a company that wants people to use its controls for mission critical applications in environments where cross-browser compatibility is important.
I can understand if Infragistics doesn't want to prepare in advance for the next release of Opera. But IE? Given IE's market share and the number of end users already using IE9 beta, they need to be more proactive where IE is concerned.
As regards to the meta tag not working, I am using the tag successfully with a broad user base. Are you sure you don't have the F12 development window open with IE9 Standards selected?
And as regards to upgrading from 2009.2...
Purchasing a subscription may be worth considering. I don't recall if the CDN was available in 2009.2, but if not, you may find the cost of the upgrade may be worth it just to get the performance benefits of the CDN.
For my part, I consider the decision to use a control on my site to go hand in hand with the decision to purchase a subscription. You never know what features (performance improvements, browser compatibility fixes, etc) will come in each service release, especially with new technologies always emerging. But that's just me.
I managed to understand why the X-UA-Compatible META tag wasn't working for me. It seems like it has to be the first tag in the <head> section.
You can read about it here:
http://evolpin.wordpress.com/2011/02/25/ie9-compatibility-and-the-meta-tag/
Wow, didn't even know that... I lucked out and put it at the top!