IE 7.0.5730.13CO Rendering Problem

Hi,
I'm a long time AW 2 user, with a commercial license.

A JS application I recently deployed has some rendering issues on:
IE 7.0.5730.13CO, XP SP2

though these issues vanish on:
IE 7.0.5730.13, XP SP2

(does anyone know what the 'CO' at the end of the version means?)

The rendering issues are many and severe, but the simplest to describe is that AW Buttons have their right sides 'chopped off', much as this post, referring to IE7 beta, describes:
http://www.activewidgets.com/javascript.forum.11618.8/ie7-beta2-button-controls-issue.html

(of course the fix mentioned in the above post does not remedy the bug in IE7)

This happens not only in my application, but on AW buttons displayed on activewidgets.com:
http://www.activewidgets.com/grid/

Suggestions would be welcome! :)

I could not find any information about IE 7.0.5730.13CO. Do you know where this version came from? How can I obtain it?

Hi,

This looked interesting, so I googled around a bit and came up with this:

The CO stands for "Corporate Administrator" ( see http://support.microsoft.com/kb/164539 ).
It indicates that the browser has been customized with Microsoft Internet Explorer Administration Kit (IEAK) (http://technet.microsoft.com/en-us/ie/bb219517.aspx)

So, my understanding is that if its working in IE 7.0.5730.13 but not in IE 7.0.5730.13CO, it would have something to do with a customization that is conflicting with AW.
I've never used IEAK or a CO version of IE - so, not sure what the problem might be.

Ankur

Hi,

Ankur:
Thanks, I didn't have any success googling around myself. Much appreciated.

Alex:
Cheers for your prompt reply.

Is AW supported on such customised deployments of IE7?

If I can determine the customisations applied to the CO build of IE7 in question, and perhaps produce an equivalent build of IE7 myself, would you be willing to debug AW against it?

I understand you might not consider this reasonable, since it is unrealistic for you to support every arbitrary build of IE7 with (possibly broken third-party) extensions.

Cheers,
-Diarmuid

Ankur,
many thanks once again for the very useful info!

Diarmuid,
yes, I would be willing to debug if you can get me this particular build. I believe the most likely reason is the following -

- the custom build disables native XMLHttpRequest object
- because XMLHttpRequest is not available AW wrongly identifies this browser as IE6 and applies IE6 CSS rules.

This could be verified if you check the value of AW._htmlClasses variable when AW is loaded in this browser -

alert(AW._htmlClasses);

If you confirm this I will try to modify browser detection procedure and hopefully it will fix the issue.

Hi Alex,
alert(AW._htmlClasses) displays:
aw-all aw-strict aw-ie aw-xp aw-xp-strict aw-ie6 aw-xp-ie6

on the IE7 CO build. So it looks like you're right!

Cheers,
-Diarmuid

Yes, this is it. I have checked that ie7 detection still works if you disable native XMLHttpRequest in the browser preferences, but apparently it breaks if this feature is disabled with IE administration kit.

I will be updating the browser detection for IE8 anyway, so it will be fixed in the next release. In the meantime if you need a quick fix, locate the following code in aw.js (line17, char878, AW 2.5.1 or line17, char680, AW 2.0.2):

if (typeof(window.XMLHttpRequest) == "object"){

and replace it with

if (document.documentElement.currentStyle.maxWidth){

I can confirm that your fix works for AW 2.5.1 on the IE7 CO build.

Thanks Alex,

-Diarmuid

Fixed in AW 2.5.2.

http://www.activewidgets.com/general.bugs/2-5-2.html