for..in statement vs. delete - ECMA compliance

VERIFIED FIXED in mozilla1.8beta1

Status

()

Core
JavaScript Engine
P4
minor
VERIFIED FIXED
13 years ago
6 years ago

People

(Reporter: Oscar Fogelberg, Assigned: brendan)

Tracking

({fixed-aviary1.0, fixed1.7.5, js1.5})

Trunk
mozilla1.8beta1
fixed-aviary1.0, fixed1.7.5, js1.5
Points:
---
Bug Flags:
blocking1.7.5 +
blocking-aviary1.0 -
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

13 years ago
User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322)
Build Identifier: js-1.5-rc6a

I believe that SpiderMonkey has a problem in the for-in implementation.

12.6.4 of ECMA-262 which defines the for-in Statement states that "If a 
property that has not yet been visited during enumeration is deleted, then it 
will not be visited"

We do not abide by this but rather SM visit properties that have been deleted 
prior to them being visited and finds them being undefined.

Reproducible: Always
Steps to Reproduce:
//Run the following script:

count = 0;
result = "";
value = "";

t = new Object();
t.one = "one";
t.two = "two";
t.three = "three";
t.four = "four";
    
for (var prop in t) {
   if (count==1) delete(t.three);
   count++;
   value = value + t[prop];
   result = result + prop;
}

Actual Results:  
value == onetwoundefinedfour
result == onetwothreefour


Expected Results:  
value == onetwofour
result == onetwofour
(Assignee)

Comment 1

13 years ago
Taking, also giving Oscar canconfirm privs.

/be
Assignee: general → brendan
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: js1.5
Priority: -- → P4
Target Milestone: --- → mozilla1.8beta
(Assignee)

Updated

13 years ago
Status: NEW → ASSIGNED
Summary: for - in statement - ECMA compliance → for..in statement vs. delete - ECMA compliance
(Assignee)

Comment 2

13 years ago
Created attachment 160432 [details] [diff] [review]
proposed fix

Easy.

/be
(Assignee)

Updated

13 years ago
Attachment #160432 - Flags: review?(shaver)
Comment on attachment 160432 [details] [diff] [review]
proposed fix

Another for the test pile! r=shaver
Attachment #160432 - Flags: review?(shaver) → review+
(Assignee)

Comment 4

13 years ago
Fixed on trunk.  Proposing for branches -- another safe ECMA conformance fix.

/be
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago
Flags: blocking1.7.x+
Flags: blocking-aviary1.0+
Resolution: --- → FIXED

Comment 5

13 years ago
Comment on attachment 160432 [details] [diff] [review]
proposed fix

a=asa for checkin to the aviary and 1.7 branches.
Attachment #160432 - Flags: approval1.7.x+
Attachment #160432 - Flags: approval-aviary+

Comment 6

13 years ago
p4 priority - not a blocker. patch approved to land.
Flags: blocking-aviary1.0+ → blocking-aviary1.0-
(Assignee)

Comment 7

13 years ago
Fixed on the branches.

/be
Keywords: fixed-aviary1.0, fixed1.7.x

Comment 8

13 years ago
Created attachment 174897 [details]
js1_5/Regress/regress-261887.js

Oscar, with your permission this will be included in the javascript test
library.
(Reporter)

Comment 9

13 years ago
Permission Granted, Thanks!
/Oscar

Comment 10

13 years ago
js/tests/js1_5/Regress/regress-261887.js checked in. Thanks Oscar!

Updated

13 years ago
Flags: testcase+

Comment 11

11 years ago
verified fixed.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.