Closed
Bug 261887
Opened 21 years ago
Closed 21 years ago
for..in statement vs. delete - ECMA compliance
Categories
(Core :: JavaScript Engine, defect, P4)
Core
JavaScript Engine
Tracking
()
VERIFIED
FIXED
mozilla1.8beta1
People
(Reporter: osfo, Assigned: brendan)
Details
(Keywords: fixed-aviary1.0, fixed1.7.5, js1.5)
Attachments
(2 files)
|
1.44 KB,
patch
|
shaver
:
review+
asa
:
approval-aviary+
asa
:
approval1.7.5+
|
Details | Diff | Splinter Review |
|
2.47 KB,
text/plain
|
Details |
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•21 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•21 years ago
|
Status: NEW → ASSIGNED
Summary: for - in statement - ECMA compliance → for..in statement vs. delete - ECMA compliance
| Assignee | ||
Comment 2•21 years ago
|
||
Easy.
/be
| Assignee | ||
Updated•21 years ago
|
Attachment #160432 -
Flags: review?(shaver)
Comment 3•21 years ago
|
||
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•21 years ago
|
||
Fixed on trunk. Proposing for branches -- another safe ECMA conformance fix.
/be
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Flags: blocking1.7.x+
Flags: blocking-aviary1.0+
Resolution: --- → FIXED
Comment 5•21 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•21 years ago
|
||
p4 priority - not a blocker. patch approved to land.
Flags: blocking-aviary1.0+ → blocking-aviary1.0-
Comment 8•20 years ago
|
||
Oscar, with your permission this will be included in the javascript test
library.
| Reporter | ||
Comment 9•20 years ago
|
||
Permission Granted, Thanks!
/Oscar
Comment 10•20 years ago
|
||
js/tests/js1_5/Regress/regress-261887.js checked in. Thanks Oscar!
Updated•20 years ago
|
Flags: testcase+
You need to log in
before you can comment on or make changes to this bug.
Description
•