bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.

inconsistent [[Array]] method handling of [Undefined] values

RESOLVED INVALID

Status

()

Core
JavaScript Engine
--
major
RESOLVED INVALID
10 years ago
10 years ago

People

(Reporter: peter seliger, Unassigned)

Tracking

1.9.0 Branch
x86
Windows XP
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

10 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5



Hallo,


I wanted to ask if mozillas implementation of array
-iterators/accessors/generators and theirs handling
of [undefined] values meets mozillas own specifications
as for instance briefly described here for [filter] ...

[https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference/Global_Objects/Array/filter#Description]

... or not - and if so why than within gecko different
appearances of [undefined] array members get handled
not consistently.

my expectation was that for this given test ...

/*
	to be run in [http://jconsole.com/]
*/
var arr01 = new Array(9);
var arr02 = [,,,,,,,,,];
var arr03 = [window.undefined, window.undefined, window.undefined, window.undefined, window.undefined, window.undefined, window.undefined, window.undefined, window.undefined];

	print("arr01.length : " + arr01.length);
	print("arr02.length : " + arr02.length);
	print("arr03.length : " + arr03.length);

	print("arr01.toSource() : " + arr01.toSource());
	print("arr02.toSource() : " + arr02.toSource());
	print("arr03.toSource() : " + arr03.toSource());

arr01 = arr01.filter(function(elm){return(!elm);});
arr02 = arr02.filter(function(elm){return(!elm);});
arr03 = arr03.filter(function(elm){return(!elm);});

	print("arr01.length : " + arr01.length); // 0 - as expected.
	print("arr02.length : " + arr02.length); // 9 - not expected at all - does mozilla fail here?
	print("arr03.length : " + arr03.length); // 9 - not expected at all - does mozilla fail here?
/*
	print("arr01.toSource() : " + arr01.toSource());
	print("arr02.toSource() : " + arr02.toSource());
	print("arr03.toSource() : " + arr03.toSource());
*/

... each of the given arrays is expected to be entirely
empty, faeturing a length of zero. for the above provided
test this behavior not only can be found for [filter] but
for every [[Array]] method where handling of [undefined]
values matters.

who is right mozilla or myself? ...


Array.prototype.filter = (function (fct, target) { // [filter] by "while"

	var arr = [];
	if (typeof fct == "function") {
		target = (((typeof target == "undefined") || ((typeof target == "obj") && !target)) ? (null) : (target));
		var i = 0, elm, len = this.length;
		while (i < len) {
			elm = this[i];
			if (typeof elm != "undefined") {
				if (fct.call(target, elm, i, this)) {
					arr.push(elm);
				}
			}
			++i;
		}
	} else {
		throw (new TypeError("1st argument needs to be a function type."));
	}
	return arr;
});

var arr01 = new Array(9);
var arr02 = [,,,,,,,,,];
var arr03 = [window.undefined, window.undefined, window.undefined, window.undefined, window.undefined, window.undefined, window.undefined, window.undefined, window.undefined];

arr01 = arr01.filter(function(elm){return(!elm);});
arr02 = arr02.filter(function(elm){return(!elm);});
arr03 = arr03.filter(function(elm){return(!elm);});

print("arr01.length : " + arr01.length); // 0 - as expected
print("arr02.length : " + arr02.length); // 0 - as expected
print("arr03.length : " + arr03.length); // 0 - as expected


... or did I get something wrong?


kind regards - Peter Seliger - pseliger@gmx.net



Reproducible: Always

Steps to Reproduce:
1a) var arr01 = new Array(9);
2a) var arr02 = [,,,,,,,,,];
3a) var arr03 = [window.undefined, window.undefined, window.undefined, window.undefined, window.undefined, window.undefined, window.undefined, window.undefined, window.undefined];

1b) arr01 = arr01.filter(function(elm){return(!elm);});
2b) arr02 = arr02.filter(function(elm){return(!elm);});
3b) arr03 = arr03.filter(function(elm){return(!elm);});

Actual Results:  
1c) alert(arr01.length); // alerts 0
2c) alert(arr02.length); // alerts 9
3c) alert(arr03.length); // alerts 9


Expected Results:  
1d) alert(arr01.length); // will alert 0
2d) alert(arr02.length); // expected to alert 0
3d) alert(arr03.length); // expected to alert 0
Created attachment 359544 [details]
reporter's testcase

This seems to work fine for me, and is consistent, the length should be 9.
Assignee: nobody → general
Component: General → JavaScript Engine
Product: Firefox → Core
QA Contact: general → general
Version: unspecified → 1.9.0 Branch
Per ECMA, elisions in array literals do not create properties; you can test this with the "in" operator (we used to, but we fixed that bug).  Providing the value "undefined" in the literal means to create a property with that value.

(filter and the other array 'extras' only operate on properties that are present.)
Status: UNCONFIRMED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → INVALID
The toSource, though changed in 3.1, though it's not this bug and it's probably more accurate in 3.1 now. See the testcase.
(Reporter)

Comment 5

10 years ago
(In reply to comment #4)
> Yes, it's correct now.

and what does this mean - does the current available script engine handle
the provided testcase correctly or not - I'm still sure handling of values
that should be considered to be [undefined] is not implemented consistently;
therefore buggy.
Reading a property that is not present produces "undefined", but it doesn't mean that there's a property named that.  You can see this with objects as well:

o = {a:"a", "b":b }
var c = o.c;
var hasC = ("c" in o); // will be false
(Reporter)

Comment 7

10 years ago
(In reply to comment #6)

ok, I think I could follow and even can accept Your argumentation.
but if You got it implemented correctly then at least the google
chrome v8 guys got it partly wrong, since my first example in both
engines runs with different results.

thanks a lot - Peter Seliger
(Reporter)

Comment 8

10 years ago
finally: [http://code.google.com/p/v8/issues/detail?id=218]

EOT - Peter
You need to log in before you can comment on or make changes to this bug.