This tests assumes a finite set of properties of the global objects. This is in contradiction with Section 16:
"An implementation may provide additional types, values, objects, properties,
and functions beyond those described in this specification."
As a matter of fact, web browsers for which the global object is also the 'window' object, there are plenty of other global object own properties. This test would be expected to fail in all web browsers.
For the record, in the IE test center (http://samples.msdn.microsoft.com/ietestcenter/), the '100%' next the the JavaScript tests seems to mean that IE9RC passes this test. Is it really the case or is the '100%' an approximation?
Hi David, I agree that this test case should not fail if extra types, values, etc. have been provided and will remove this assertion shortly. I would not necessarily expect this test to fail in all web browsers though - if vendor provided types such as 'document'/'screen'/etc. are not enumerable the test will pass.
As for IE Test Center, just double-checked and the test passes on my machine (32-bit Windows 7 RTM, English language OS, IE9 RC1): "15.2.3.4-4-1 Object.getOwnPropertyNames returns array of property names (Global): pass [Source]". I also just verified the following returns a 'true' alert outside of IE Test Center's harness:
<html><body><script type="text/javascript">
document.write("This is my first JavaScript!");
function fnGlobalObject() {return this};
function testcase() {
var result = Object.getOwnPropertyNames(fnGlobalObject());
var expResult = ["NaN", "Infinity", "undefined", "eval", "parseInt", "parseFloat", "isNaN", "isFinite", "decodeURI", "decodeURIComponent", "encodeURI", "encodeURIComponent", "Object", "Function", "Array", "String", "Boolean", "Number", "Date", "Date", "RegExp", "Error", "EvalError", "RangeError", "ReferenceError", "SyntaxError", "TypeError", "URIError", "Math", "JSON"];
var result1 = {};
for (var p in result) {
result1[result[p]] = true;
}
for (var p1 in expResult) {
if (!result1[expResult[p]]) {
return false;
}
}
return true;
}
alert(testcase());
</script></body></html>
Have you tried running this from IE9 RC1, and if so how does your machine setup differ from mine (e.g., I could imagine potential localization problems with this one)?
Thanks again for reporting this!
Dave
(In reply to comment #1)
> Hi David, I agree that this test case should not fail if extra types, values,
> etc. have been provided and will remove this assertion shortly. I would not
> necessarily expect this test to fail in all web browsers though - if vendor
> provided types such as 'document'/'screen'/etc. are not enumerable the test
> will pass.
Object.getOwnPropertyNames returns an array with ALL own properties, not only enumerable (15.2.3.4 step 4).
> As for IE Test Center, just double-checked and the test passes on my machine
> (32-bit Windows 7 RTM, English language OS, IE9 RC1): "15.2.3.4-4-1
> Object.getOwnPropertyNames returns array of property names (Global): pass
> [Source]". I also just verified the following returns a 'true' alert outside
> of IE Test Center's harness:
> <html><body><script type="text/javascript">
> document.write("This is my first JavaScript!");
> function fnGlobalObject() {return this};
>
> function testcase() {
> var result = Object.getOwnPropertyNames(fnGlobalObject());
> var expResult = ["NaN", "Infinity", "undefined", "eval",
> "parseInt", "parseFloat", "isNaN", "isFinite", "decodeURI",
> "decodeURIComponent", "encodeURI", "encodeURIComponent", "Object", "Function",
> "Array", "String", "Boolean", "Number", "Date", "Date", "RegExp", "Error",
> "EvalError", "RangeError", "ReferenceError", "SyntaxError", "TypeError",
> "URIError", "Math", "JSON"];
>
> var result1 = {};
> for (var p in result) {
> result1[result[p]] = true;
> }
>
> for (var p1 in expResult) {
> if (!result1[expResult[p]]) {
> return false;
> }
> }
> return true;
> }
> alert(testcase());
> </script></body></html>
>
>
> Have you tried running this from IE9 RC1, and if so how does your machine setup
> differ from mine (e.g., I could imagine potential localization problems with
> this one)?
Unfortunately, on my machine I have a double-boot Windows XP/Ubuntu, so I can't run IE9 for the moment.
I have found a weird thing. On the harness, the test fails on FF4b12. However, on the web console, your code snippet passes.
I think I have figured why... There is a typo:
for (var p1 in expResult) {
if (!result1[expResult[p]]) {
return false;
}
}
should be:
for (var p1 in expResult) {
if (!result1[expResult[p1]]) {
return false;
}
}
In the "if" test, "p" should be "p1". Basically, depending on the last value of p, if it is in expResult, test passes and it doesn't if p isn't. I think that FF4b12 WebConsole adds things to global object, so it may change the global object properties order.
Actually, I think I misunderstood the test. Just to make sure. Is the test testing that expResult is included in Object.getOwnPropertyNames(fnGlobalObject())?
If it's the case, then, the test is actually fine (without the typo) and there is no need to worry about implementation-specific values. I thought it was checking for equality of the two sets.
For the record, once again, Object.getOwnPropertyNames() returns an array and since ES5, arrays have amazing methods to deal with them. On the other hand, for..in loops loop through all enumerable properties of the object (on the prototype chain too).
To test array inclusion in our case, I would go for:
----------------------
function testcase() {
var result = Object.getOwnPropertyNames(fnGlobalObject());
var expResult = [...];
// Make sure that every element in expResult can be found in result
return expResult.every(function(e){return result.indexOf(e) !== -1;});
}
----------------------
> Actually, I think I misunderstood the test. Just to make sure. Is the test
> testing that expResult is included in
> Object.getOwnPropertyNames(fnGlobalObject())?
> If it's the case, then, the test is actually fine (without the typo) and there
> is no need to worry about implementation-specific values. I thought it was
> checking for equality of the two sets.
Yes, the intent of the test is to ensure expResult is in Object.getOwnPropertyNames(fnGlobalObject()). Closing this as By Design.
(In reply to comment #3)
> > Actually, I think I misunderstood the test. Just to make sure. Is the test
> > testing that expResult is included in
> > Object.getOwnPropertyNames(fnGlobalObject())?
> > If it's the case, then, the test is actually fine (without the typo) and there
> > is no need to worry about implementation-specific values. I thought it was
> > checking for equality of the two sets.
> Yes, the intent of the test is to ensure expResult is in
> Object.getOwnPropertyNames(fnGlobalObject()). Closing this as By Design.
oh but and what about the typo?
Typo is fixed in all source control repositories, but not yet live on the website.