494896 - functions assigned in a loop in window scope are not unique

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect, P1)

Description

[same]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3

//example 1

var a = [{},{}];

for(var i = 0; i < a.length; ++i) a[i].f = function(){};

alert(a[0].f === a[1].f);
//expect "false"
//result "true"


//example 2

var a = [{},{}];

(function(){ for(var i = 0; i < a.length; ++i) a[i].f = function(){}; })();

alert(a[0].f === a[1].f);
//expect "false"
//result "false"



Reproducible: Always

Comment 1

[Jesper Hansen]

Even simplify it more:

a = function(){}; 
b = function(){}; 
a === b 
Returns false.
b === b
returns true.

You want true in both cases.
I'd believe such a compare would treat to compare the two as prototypes. In which case it would be true... But a == b is false because a is not b in which case it will always be false.

The use-case for === is: Returns true if the operands are equal and of the same type.

Comment 2

[same]

I expect a[0].f and a[1].f to be distinct references in both cases (they are not in example 1, are in example 2 with the only difference being the assignment of the f property inside an anonymous function).

Comment 3

[Jesper Hansen]

After investigating a little more and some discussion with mzz in #firefox,
then its found that 

var a = [{},{}];
for(var i = 0; i < a.length; ++i) a[i].f = function(){};
alert(a[0].f === a[1].f);

In fact returns true on a webpage, but returns false in .xul documents
(including browser.xul which I tested against).

Should be found out why we have this difference.

Comment 4

[Jesper Hansen]

It seems to be some strange cases where it actually returns true on a webpage, but to always get it to return true:
Copy to url bar:
data:text/html;charset=utf-8,<script>%0D%0Avar a %3D [{}%2C{}]%3B%0D%0Afor(var i %3D 0%3B i < a.length%3B %2B%2Bi) a[i].f %3D function(){}%3B%0D%0Aalert(a[0].f %3D%3D%3D a[1].f)%3B%0D%0A<%2Fscript>

This renders true in Firefox 3.0 and false in Firefox 3.5

Comment 5

[Mike Shaver (:shaver emeritus)]

Aye, blocking. :-/

Comment 6

[Jesper Hansen]

Ignore the data:uri in comment #4 as bugzilla have broken it. I have updated the URL of the bug instead to reflect this.

Comment 7

[Andreas Gal :gal]

I can't reproduce this bug with TM tip.

Comment 8

[Andreas Gal :gal]

I can't reproduce this in a 1.9.1 debug shell.

Comment 9

[Andreas Gal :gal]

This returns true in 3.0, which I think is wrong. It correctly returns false in 3.5/TM/trunk and branch (1.9.1). In other words this is correct in 3.5, but wrong in 3.0. Should this be documented?

var a = [{},{}];

for(var i = 0; i < a.length; ++i) a[i].f = function(){};

alert(a[0].f === a[1].f);

Suggested action: unblock for 3.5 (its fixed), but bisect and find fix.

Comment 10

[Andreas Gal :gal]

We need a reverse regression window (going back in time until this breaks).

Comment 11

[Ria Klaassen (not reading all bugmail)]

Not sure if I understand it correctly, but this was fixed on trunk on 20 Apr 2009:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d056669074c7&tochange=57213af4a45d

Talking about the first example in comment 0.

Comment 12

[Ria Klaassen (not reading all bugmail)]

(In reply to comment #11)

Err it was 7 Apr 2009 (verified).

Comment 13

[Matt]

Why is "regressionwindow-wanted" needed? What is missing?

Comment 14

[(mostly gone) XtC4UaLL [:xtc4uall]]

(In reply to comment #11)
Removing the KW.
Must have been fixed by Bug 479198, Bug 481514 or Bug 452498 (Typo in the Pushlog)) and all of them landed on TM Branch on the same Day and on 1.9.1 Branch too.