New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 8 users

Issue metadata

Status: Fixed
Owner:
Closed: Dec 2015
Cc:
Components:
HW: ----
NextAction: ----
OS: ----
Priority: 2
Type: Bug



Sign in to add a comment
link

Issue 3056: getOwnPropertyNames does not return names in the insertion order

Reported by arv@chromium.org, Dec 11 2013 Project Member

Issue description

var o = {};
for (var i = 0; i < 10; i++) {
  o['_' + String.fromCharCode(i)] = i;
}
Object.getOwnPropertyNames(o).map(function(n) { return o[n]; })

Returns

[4, 1, 2, 3, 9, 6, 7, 0, 8, 5]

but the expected result is

[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]

This is because the object is in slow mode due to the non ascii identifiers. The same thing happens if the keys are all ascii but there are too many or we delete a key. In other words in happens to all slow mode object.

This is not a violation of ES5 or ES6 but it might be unexpected
 

Comment 1 by adamk@chromium.org, Aug 18 2015

Cc: adamk@chromium.org
Labels: Area-Language Harmony
Owner: ----
Status: Available
This is now a spec violation, per http://www.ecma-international.org/ecma-262/6.0/#sec-ordinary-object-internal-methods-and-internal-slots-ownpropertykeys, which requires insertion order.

Also, another test case, from mridgway@yahoo-inc.com on  issue 4118  (the object is in dictionary mode due to too many keyed stores):

var t = {}; 'abcdefghijklmnopqrst'.split('').forEach(function (letter) { t[letter] = letter; }); Object.getOwnPropertyNames(t);
> ["g", "b", "h", "a", "t", "c", "f", "r", "k", "e", "p", "l", "q", "n", "s", "m", "o", "j", "i", "d"]

Comment 2 by adamk@chromium.org, Nov 16 2015

Owner: neis@chromium.org
Status: Assigned

Comment 3 by jkummerow@chromium.org, Nov 17 2015

Cc: cbruni@chromium.org
The dictionary backing store already keeps track of the insertion/enumeration indices. JSObject::MigrateSlowToFast shows how to iterate over a dictionary in enumeration order. Dictionary::CollectKeysTo and Dictionary::CopyEnumKeysTo should learn from that example.

Comment 4 by jkummerow@chromium.org, Nov 17 2015

Ignore #3. After https://codereview.chromium.org/1453583002/, I think the way to fix it is to use JSReceiver::GetKeys() from Runtime_GetOwnPropertyNames.

Comment 5 by mridg...@yahoo-inc.com, Dec 7 2015

Is `Object.assign` using `hasOwnProperty` internally or should I create a new issue for `Object.assign`'s behavior? Right now calling `Object.assign` on one of the example objects above will change the order of the new object's `Object.keys`:

var t = {}; 'abcdefghijklmnopqrst'.split('').forEach(function (letter) { t[letter] = letter; }); Object.keys(Object.assign({}, t));
> ["g", "b", "h", "a", "t", "c", "f", "r", "k", "e", "p", "l", "q", "n", "s", "m", "o", "j", "i", "d"]

I just want to make sure that this behavior gets resolved as well.

Comment 6 by caitpott...@gmail.com, Dec 7 2015

Object.assign does not use `hasOwnProperty` internally, but it does only deal with own property keys, provided the runtime function it relies on isn't broken.

Comment 7 by caitpott...@gmail.com, Dec 7 2015

FWIW, on ToT:

```
Echo:v8 caitp$ out/x64.release/d8 
V8 version 4.9.0 (candidate)
d8> var t = {}; 'abcdefghijklmnopqrst'.split('').forEach(function (letter) { t[letter] = letter; }); Object.keys(Object.assign({}, t));
["a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k", "l", "m", "n", "o", "p", "q", "r", "s", "t"]
d8>   
```

Comment 8 by jkummerow@chromium.org, Dec 8 2015

Cc: neis@chromium.org
Owner: jkummerow@chromium.org
Status: Fixed
Indeed, #4 happened in crrev.com/7d1263db477c812d40789c75be2f368e4c0b9769. The test cases mentioned in #1 and #5 work correctly now.

Comment 9 by hablich@chromium.org, Mar 23 2017

Labels: Priority-2

Sign in to add a comment