The link (MS 2909921) is another set of IE security holes that have been
patched. That's security, not functionality. The following seems to be
the problem with browser compatibility, ie lots of different JS files
and not a single cross browser implementation:
find . -name ClientCore.js
./moz_noopt/javascript/ClientCore.js
./moz/javascript/ClientCore.js
./saf_noopt/javascript/ClientCore.js
./ie_noopt/javascript_ie9/ClientCore.js
./ie_noopt/javascript_ie11/ClientCore.js
./ie_noopt/javascript_ie10/ClientCore.js
./ie_noopt/javascript_ie8/ClientCore.js
./ie/javascript_ie9/ClientCore.js
./ie/javascript_ie11/ClientCore.js
./ie/javascript_ie10/ClientCore.js
./ie/javascript_ie8/ClientCore.js
This practice has not been common for a decade or so. I really hope
engineering are not trying to maintain all those versions! But diffing
them suggests they are, ie.
diff ./ie_noopt/javascript_ie11/ClientCore.js
./ie_noopt/javascript_ie10/ClientCore.js
< e.style.opacity=".20"; e.style.filter =
"progid:DXImageTransform.Microsoft.Alpha(Opacity=20)";
---
> e.style.opacity = ".20";
Styling goes in the stylesheet - not the Javascript!
> try
> {
> window.event.keyCode=arg;
> }
> catch (e)
> {}
Wait, this isn't right. The javascript catches the error and throws it
away without logging to console. So I looked harder:
grep "catch" ./ie_noopt/javascript_ie11/ClientCore.js| wc -l
137
137 catch statements? Well, I guess that's error handling. I wonder what
they do:
grep "catch" ./ie_noopt/javascript_ie11/ClientCore.js
}catch(ex){}
} catch(ex){}
} catch(ex){}
...
(and it goes on.)
So, someone has been "solving" bugs in Mid Tier by catching the
exception, throwing it away, and carrying on regardless.
In summary, IE11 has nothing to do with the problem - IE isn't such a
bad browser now-a-days. The problem is the quality of the Javascript.
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"
