Path: csiph.com!usenet.pasdenom.info!news.albasani.net!feeder.erje.net!eu.feeder.erje.net!eweka.nl!lightspeed.eweka.nl!193.141.40.65.MISMATCH!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail Content-Type: text/plain; charset="UTF-8" Message-ID: <106527179.0dF1VmtKRI@PointedEars.de> From: Thomas 'PointedEars' Lahn Reply-To: Thomas 'PointedEars' Lahn Organization: PointedEars Software (PES) Date: Mon, 18 Nov 2013 18:52:35 +0100 User-Agent: KNode/4.10.5 Content-Transfer-Encoding: 8Bit X-Face: %i>XG-yXR'\"2P/C_aO%~;2o~?g0pPKmbOw^=NT`tprDEf++D.m7"}HW6.#=U:?2GGctkL,f89@H46O$ASoW&?s}.k+&. <1581559.TFT1m0cKLP@PointedEars.de> <528a0736$0$6566$9b4e6d93@newsspool4.arcor-online.net> MIME-Version: 1.0 Lines: 176 NNTP-Posting-Date: 18 Nov 2013 18:53:33 CET NNTP-Posting-Host: 2fa4bca6.newsspool2.arcor-online.net X-Trace: DXC=dV[o\0NVl9@Aa;:RKVJ>LEA9EHlD;3YcB4Fo<]lROoRA8kFdWjfmTBDZm8W4\YJNLYUVHKH;GI^G;S2JoZ]LBUNdWjda=A>h8I X-Complaints-To: usenet-abuse@arcor.de Xref: csiph.com comp.lang.javascript:22044 Christoph Michael Becker wrote: > Thomas 'PointedEars' Lahn wrote: >> Christoph Michael Becker wrote: >>> In IE11 >> Fascinating. > > -v, please. I was not aware that there is a new version. >> See also , and the >> corresponding test cases. > > This reports now: > > | This user agent: > | Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; SLCC2; .NET CLR > | 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC > | 6.0; .NET4.0C; rv:11.0) like Gecko > | > | This ECMAScript implementation: > | undefined Thank you, fixed. See below. With IE/MSHTML/JScript (6 and – possibly through – 9) there is still one bug that I could not find the reason for and fix yet: | SCRIPT1002: Syntax error | es-matrix, line 1294 character 1 (translated from German) Do you see it? > However, the version number string algorithm given by you, says: > > | JScript 11.0.16428 > > On Saturday, when I submitted the results on the ES matrix, it must have > been: > > "JScript 11.0.16428" on > "Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko > > (I have gotten some Windows updates in the meantime.) I have also updated the Matrix in the meantime to sort “new ActiveXObject” (and similar code) under “A” (first letter of the constructor identifier), not “N”. This appears to have awoken, through cache control (later Last- Modified date etc.), a sleeping refactoring bug in JSX:engine.js (responsible for implementation and version detection) that is fixed now. >>> the following is true[1]:In >>> >>> typeof window.ActiveXObject == "undefined" >> >> […] >> That said, is “new ActiveXObject(…)” or “new window.ActiveXObject(…)” >> supported then? If not, everything works as designed. > > That is exactly the point. Calling ActiveXObject() works as expected, > but the ActiveXObject property is undefined. > > It occurs to me, Microsoft has done this to cater for scripts using > unrelated existence inference ( if (ActiveXObject) // assume IE ). > IMVHO that doesn't seem to be prudent. ACK. In that case I would have to update JSX:http.js because it uses the “typeof” test through jsx.object.isMethod(). Presumably, several other people would have to update their libraries as well (or decide to screw IE 11 and make Micro$~1 come to their senses – but that is not likely to happen). >> “ActiveXObject” is a very old feature which repeatedly introduced >> security leaks in MSHTML-based applications and Windows; I would not be >> surprised if it was finally removed from the JScript language as a >> result. For example, “file:” URIs aside, you do not need “ActiveXObject” >> for XHR in recent JScript versions; use “new XMLHttpRequest()” instead >> (like almost everywhere else). > > I try to avoid ActiveXObject generally, but I stumbled over the issue in > a third party library, which deals with parsing XML, and tries to > fallback on ActiveXObjects when XSLTProcessor is not available. ACK. >>> This causes isHostMethod()[2] to fail. >> >> AFAICS (I have just tested this positive in IE 6.0.2800.1106 on Wine XP >> which can create, for example, "Microsoft.XMLHTTP" objects), >> “ActiveXObject” always referred to a *native* method, and yielded >> "function" (not "unknown") as result of a “typeof“ operation. AFAIK it >> is a built-in JScript feature even though it creates only host objects, >> and is therefore tested with the ES Matrix. > > I hadn't even noticed the test for new ActiveXObject() there -- however, > the matrix reports: > > | Test 1: failed That was to be expected. I would have to use try…catch now if “typeof” did not work. (A test for functionality appears to be impossible because I cannot know which COM server names and type names are available.) >>> Is there a reliable solution to detect if the window object has an >>> ActiveXObject method, without actually /try/ing to instantiate a new >>> ActiveXObject? >> >> Depends. try…catch at least is the only reliable way to determine >> whether a host object of a certain class (sic!; as in CLSID) can be >> successfully created when “ActiveXObject” is called as a constructor >> where try…catch is supported (that would apply to these versions of >> JScript). > > ACK. However, I was hoping to be able to test for existance of the ^e > ActiveXProperty before actually trying to call it. ^^^^^^^^Object property You could do try { ActiveXObject } catch (e) { /* no ActiveXObject */ } but since you have to do var o = null; try { o = new ActiveXObject("…"); } catch (e) { // … } anyway, the former does not make much sense. It might even throw an exception even if “ActiveXObject” is supported because the method was used wrong. It walks like a native method, but we can see in the MSDN Library that it quacks rather strangely. >>> [1] >>> [2] >>> >> scripting> >> >> There are three versions of isHostMethod() there – which one have you >> used? > > The one in the section called "A good set of host object testing > functions". As you can see, one can do better. >> JSX:object.js has another one. However, following my argument above, >> Peter Michaux’s argument is flawed and none of those methods should be >> used on “ActiveXObject”. > > That was probably my mistake. Peter Michaux doesn't mention this > particular test in the article. ACK. -- PointedEars Twitter: @PointedEars2 Please do not Cc: me. / Bitte keine Kopien per E-Mail.