New issue
Advanced search Search tips
Starred by 54 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Oct 2008
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Compat

  • Only users with Commit permission may comment.

Sign in to add a comment

for in loops don't occur in defined order

Reported by, Sep 3 2008 Back to list

Issue description

Product Version      : (1583)
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
     Safari 3: OK
    Firefox 3: OK
         IE 7: OK

What steps will reproduce the problem?
1. Go to the above URL.

What is the expected result?
Both sets of results should be "1: first 2: second".

What happens instead?
The first result is "1: second 2: first".

Please provide any additional information below. Attach a screenshot if

It appears as if when performing a loop over an object - if one of
the properties contains an array (may happen with other objects, haven't
tested) it will iterate that object's properties in a different order than
in which they were defined. This is affecting sites which rely upon this
Labels: -Area-Unknown Area-Compat
[HAS-REDUCTION] This is a known issue. 

0 bytes Download
456 bytes View Download

Comment 2 by *, Sep 23 2008

Labels: Has-reduction Chrome-specific
Status: Untriaged (was: NULL)
Reduction can be accessed by http://go/reductions/883/test-quirks.html

Comment 3 Deleted

Looks like this got fixed. Both the website and reduction show expected behavior. Google Chrome (Official Build 4058)
Status: WontFix (was: NULL)

Comment 6 by, Oct 31 2008

Did you mean Status: Fixed?

Comment 7 by Deleted ...@, Nov 11 2008

Tested with Google Chrome and still doesn't work, so doesn't seems to be
fixed, the properties of the array are still iterated in an order different than they
were defined. It look quite random though.

410 bytes View Download

Comment 8 by, Nov 13 2008


The chrome.html still shows error with Chrome (Official Build 5194)
gvalentin, bksening: FYI, the previous testcases and the original site work fine. The 
chrome.html might be related to  Issue 3867 

Status: WontFix - mean will NOT be fixed?

Pretty serious bug for our company.

Comment 11 by, Dec 18 2008

Guys this is not a bug.
Page 6, near the bottom.  "The order in which item is bound to members of collection
is implementation dependent."
I would say that the reasoning behind not keeping it in the order it was created was
to keep the engine fast and lean.  Remembering the order that elements were inserted
into an object requires time and, well, memory.
So they won't fix it.  And I for one agree with that.

Comment 12 by, Dec 18 2008

@stav.roy: The specification does not define how an implementation should handle it -
therefore an implementation should conform with other implementations. Considering
that every single other popular ECMAScript implementation implements the same
property looping type it becomes that much more important to try and get it right.
I'm sure you get pissed when Internet Explorer goes off and does something different
from every other browser (especially when it causes a regression to occur) - the same
should be happening here.

The argument that they're doing it to "keep the engine fast and lean" is bogus. There
are two other, faster, ECMAScript engines out there: SquirrelFish and TraceMonkey and
they both implement the looping indentically.

I just want to emphasize the point: This change makes V8 work differently from every
other major ECMAScript implementation and causes actual, real world, code to break.
There is no reason why this shouldn't be fixed.

Comment 13 by, Dec 18 2008


I respectfully disagree with the sentiment.  However, I had not considered that this
might actually cause real life code to break.  Personally, I absolutely do not build
hashes and expect their members to remain in the order I built them.  I was not even
aware that the other implementations kept their order until coming across this issue.
 Now that I know that there is code out there in the wild that requires this behavior
then of course I agree this should be changed so that the internet will not break
(again).  Ideologically, however, I would rather see all other implementations change
the way *they* work so that none of them agree and that way people won't be tempted
to rely on something that shouldn't exist.

On a personal note, my coworker is very angry with me for upsetting you.  In my
defense I hadn't noticed you were the one who opened the bug report :-)
We are all huge fans of yours; keep up the awesome work!

Comment 14 by Deleted ...@, Jan 8 2009

"Remembering the order that elements were inserted
into an object requires time and, well, memory.
So they won't fix it.  And I for one agree with that."

Not sure what the side comment means - I can't see a 'star icon'

Anyway, I agree with the above - expecting a hash to be ordered is stupid.

I agree with jeresig, would like Chrome's implementation to work the same as every
other browser when it comes to for-in loops.

I see this is marked WontFix? 

Comment 16 by Deleted ...@, Mar 18 2009

Un-fucking-believable that the developer thinks this is ok.

Comment 17 by Deleted ...@, Mar 18 2009

Chrome looks more and more like old versions of IE in terms of the amount of work it
requires to adjust JavaScript code to its "quirks".

Comment 18 by, Apr 11 2009

Holy moley, this bug just broke my code! Um, hello people, JSON is used for
everything these days! Order is quite important!

Comment 19 by, Apr 12 2009

I have an idea--if the common implementation which tons of code depends on doesn't
match the specification, let's change the specification!
Tell me about it.  Or, you can just block the offending browser, as we have had to do on our site.
Is there a way to retrieve the original enumeration order since doing will
not return the order the elements are defined?

Comment 22 by Deleted ...@, May 13 2009

...from the JSON spec "An object is an unordered set of name/value pairs".  That 
given, I wholly agree that utility outweighs the letter of the law in this case.  You 
can't support innerHTML then elect not to follow suit with JSON object order.

Comment 23 by, May 13 2009

This ideological dissonance springs from the nature of JSON itself--object literal
notation adapted into something it wasn't designed for: a data protocol. In hashes we
don't expect first-in-first-out behavior, but in data protocols we do.

Comment 24 by, May 18 2009

Here is a kind of workaround: if we add any non-digital character before the index 
itself (like 'i385' insted of '385'), chrome starts to behave like other browsers.
See  bug #12169  for more details and code examples.

Comment 25 by, May 28 2009

ECMAScript 5 defines the order of iteration as being the order of insertion, that means 
this behaviour is now non-actual standard, in addition to just being non-defacto 
Hello folks,

I've opened another issue for this bug (as this is still a problem and is
inexplicably closed as wontfix):

I'd urge you to star that issue and put your comments,updates.

Also, someone there wants a list of sites affected. To the extent possible, can you
please add yours in?

Thanks a ton.

Especially I love the comment in PropertyMapHashTable.h of SquirrelFish:
// lastIndexUsed is an ever-increasing index used to identify the order items
// were inserted into the property map. It's required that getEnumerablePropertyNames
// return the properties in the order they were added for compatibility with other
// browsers' JavaScript implementations.

So, V8 is fast and lean b/c you guys want to reorder object properties in order to reduce cache size and 
increase hit rate, right? And SquirrelFish is not fast and lean according to this logic? And yes, MS did prefer 
UTF16, b/c they were not able to write a fast sort function for UTF8. Crap.

As Google does not seem to have the resources for further investigation, I will invest my time to do it, even 
after I came home at 6 am this morning and today is Sunday^^
3.0 KB View Download
So, the mystery is solved... it's not the suspected property address caching (yeah!),
but a if/else construct that appears throughout The comment in
GetObjectProperty basically tells everything. Nevertheless Chrome is a great browser.
Just let me state, that I don't consider this copy&paste stuff good coding style nor
am I satisfied with the feedback from Google for this ticket... basically I posted
the same problem as #223, but it took a Mr Resig to escalate the issue and not even
that resulted in a fix. What you need here is a refactoring of the code, to get it
really fixed in a way that is compatible to other browsers. And maybe some more
useful comments like SquirrelFish :)

GetObjectProperty (line 2559):
  // Check if the name is trivially convertible to an index and get
  // the element if so.
  if (name->AsArrayIndex(&index)) {
    return GetElementOrCharAt(object, index);
  } else {
    PropertyAttributes attr;
    return object->GetProperty(*name, &attr);

SetObjectProperty (line 2670):

  if (key->IsString()) {
    Handle<Object> result;
    if (Handle<String>::cast(key)->AsArrayIndex(&index)) {
      ASSERT(attr == NONE);
      result = SetElement(js_object, index, value);
    } else {
      Handle<String> key_string = Handle<String>::cast(key);
      result = SetProperty(js_object, key_string, value, attr);
    if (result.is_null()) return Failure::Exception();
    return *value;

Keep up the good work!

Comment 29 by, Nov 21 2009

I'm confused by this statement, "ECMAScript 5 defines the order of iteration as being
the order of insertion, that means this behaviour is now non-actual standard, in
addition to just being non-defacto standard."

From what I can see from 12.6.4 at
on the loop, "The mechanics and order of enumerating the not

I'm also confused because it seems like Chrome is working fine with iteration.

If it is true that "order of iteration" is the "order of insertion", being within loops should presumably be an exception since properties inserted there are
not supposed to be iterated ("If new properties are added to the object being
enumerated during enumeration, the newly added properties are guaranteed not to be
visited in the active enumeration." sec. 12.6.4)).

One item I do not see specified in the spec is whether deletion of properties should
require reinsertion of a given key to be added back retaining no memory of the
previous deleted properties' order. Explorer does apparently retain such memory,
preventing objects from being universally sortable across browsers (without the
object itself being wholly redefined).

Note that the problem in the following (in IE) is not order, but retension
of order info on deleted properties since reinserting a deleted property will see it
added back in its previous relative order, not after the other properties:

function reverseObj (obj) {
  var keys = [], vals = [];
  for (var p in obj) {
    delete obj[p];
  for (var i=0; i < keys.length; ++i) {
    obj[keys[i]] = vals[i]; // In IE the original property order is remembered,
despite having been deleted above!
var assoc = {a: 'orange', b: 'banana', c: 'apple', d: 'lemon'};
reverseObj(assoc); // No effect in IE, but does in all other browsers

As someone who finds it extremely useful to not only iterate objects in order, but
also have control over their sequence, I hope that if the new spec does require
iteration to follow order of insertion, that insertion will also be required to
disregard previously deleted properties.
 Issue 12169  has been merged into this issue.

Comment 31 by, Feb 20 2010

This issue is still breaking a number of web sites I have built. Is there any chance that 
this issue will be re-opened and fixed, or do I need to begin rewriting my code? Also, 
is there any hack or workaround I can use without restructuring my data?

My test case is:
	var arr = {
		'b': 'defined first',
		'2': 'defined second',
		'a': 'defined third',
		'1': 'defined fourth'

	var out = '';
	for(var i in arr) out += arr[i] + '<br />';

	window.onload = function() {
		document.body.innerHTML = out;

The output in most browsers is:
defined first
defined second
defined third
defined fourth

While the output in Chrome is:
defined fourth
defined second
defined first
defined third

I am running Google Chrome 5.0.307.9 beta on Mac OS X 10.5.8.

Chrome appears to be taking the numeric keys, reordering them, and placing them 
at the start, while leaving the order of non-numeric keys otherwise intact.
The only workaround is the one you kind of alluded to.  Change your keys to include
some non-numeric character at the front.  Chrome will maintain the given order unless
it sees numeric keys, although that isn't guaranteed to stay that way.

So, add the extra character, and remove with it when processing the selection.

Or, make your users use something other than Chrome.

Comment 33 by, Feb 20 2010

I'm embarrassed now, since I just noticed  Issue 20144 , which has the status "Assigned," 
so it looks like we may yet get a fix. Please ignore comment 31....
Opera 10.50 behaves like Chrome... 

They will do everything for "the fastest browser" label :(
So I've noticed.

Can we please get some clarification on the status of this issue?
Developers seem conflicted about whether or not to conform to the precedent set by other browser vendors 
or to just say the hell with everyone and the difficulties this presents to utilization of JSON. It's 
everyone else's fault for relying on logical behavior, unspecified though it may be.
OK, it's getting clear that the ECMAScript specification is a useless in this topic 
(if there's someone i charge, pls act and propose more specific specification).

Anyway, de-facto standards are standards too, and hopefully upon a request of all the 
desperate developers, V8 guys will decide to sort this out.

There's an open issue for exactly the same, if you are still interested, please vote 

Btw i already checked out the V8 bleeding edge source, and my finger is on the delete 
button to get these problematic conditions out of there... :)

Comment 37 by, Oct 13 2010

Still not fixed in Chrome 6.

Comment 38 Deleted

Comment 39 by, Jan 16 2011

What is the official word on this?

Comment 40 by, Jan 16 2011

The official word, as set by the Chromium devs in Comment 5, and also in the left-side
info summary is Status:WontFix.  That is, the current behavior will not be fixed/changed.

Comment 41 by, Jan 16 2011

OK. Making the object identifier a string is a good workaround in that case.

Comment 42 by Deleted ...@, Feb 6 2011

I have an Internet application that uses objects a lot.
I get the objects from the serever (json_encde).
When I open them in other browsers (IE, FireFox) the order is OK.
When I open in chrome it sorts the objects by texts and I cannot get the origional order. I cannot support Chrome because of that.
Is there a way to overcome this gigantic problem.!!!

Comment 43 Deleted

Comment 44 by, Feb 10 2011

I raised a similar issue, but not the same issue as reported.

See  issue #72652 

Comment 45 by Deleted ...@, Mar 17 2011

Let's get some reality here.

1. Objects are not specified as having to return properties in
   any particular order

2. Browsers have in the past been deomonstrated to not return
   properties in any particular order

3. Browsers continue to not return properties in any particular order
   in some cases

4. There are various quirks in property ordering, such as:

   - some browsers always return numeric properties first

   - Firefox returns properties on window in reverse order

   - IE returns array properties in the order they are added but
     other browsers return them in index order

   - Deleted and re-added properties keep their original position
     in some browsers but not others

So much for "standard behaviour" - there isn't one.

Anyone who depends upon non-standard behaviour in such circumstances because they observed a particular behaviour in two or three browsers deserves what they get.

Comment 46 by Deleted ...@, Mar 17 2011

I think it may have already been pointed out in this thread already, but we talking about objects, not arrays.

Also, the comment about "properties on window" doesn't add anything to your argument. I think that properties should be returned in defined order. If Firefox defined them in "reverse" order, then they should be returned in "reverse" order. The behavior you describe seems to be in line with the de facto standard.

The fact that some browsers do not exhibit the desired behavior does not make it any less desirable.

Comment 47 by, Mar 20 2011

Regardless of the desirability, the fact that no ordering behaving is defined in the
standards does not make this any more a real bug.

Comment 48 by, Mar 20 2011

The de facto/expected behaviour should be used.

Comment 49 by, Mar 22 2011

I'm just reading this issue with an expression of disbelief on my face.
Is it really true that programmers, in the face of an existing,
established standard, rely on reverse-engineered non-standard behavior
of certain browsers, and then demand that all other browsers change
their behavior so the code of these stupid programmers does not break?

I would like to see beginners leave this discussion and leave the issue
to the professionals. We are not playing in a sandbox here.
Are you serious?

If all programmers programming for the web exclusively followed established
standards, nothing would have worked on IE at all.  Ever.

The fact of the matter is that portions of frameworks were built around this
specific behavior.

Are you telling us that you've never taken advantage of this particular
behavior?  That, when using key/value pairs to keep track of drop down list
elements, you also keep a separate sort order?  Do you spend time writing
routines that bypass normal framework operations to avoid this issue?

This isn't a matter of being in a sandbox.  This behavior exists in the
wild.  In real life.  In a lot of browsers.  We'll just stop using Chrome,
if necessary.  It becomes a business decision.

I noticed that IE 9 does seem to follow this non-standard behavior as well,
although early reports were that it wouldn't.

Comment 51 by, Mar 22 2011

"The order in which item is bound to members of collection is implementation dependent." -

Thus, the "established standard" is the de facto one set by existing implementations.

Comment 52 by, Mar 22 2011

Let's not resort to name-calling here.

Not a single browser implemented HTML as SGML. Should a newcomer implement their browser as SGML and then triumphantly point the fingers at how everyone else failed to do so?

And the (still) main contenders, IE and Firefox, did pretty well in sticking to a (mostly) predictable ordering until everyone decided to go their own directions. 

And I'm sorry but the web is certainly not just for professionals (even though I and no doubt many others here also arguing our position happen to be one). If people can get away with something, expect it to be interpreted that way.  Fortunately the WhatWG is not taking the attitude of screwing large numbers of people just because they or the browsers had followed a different practice from what someone wrote in a technical (and hardly user-friendly) specification, but are taking into account actual usage, and from the popularity of this issue, I'd say there are no small number of people using it this way.

Comment 53 by, Mar 22 2011

@51, what a stupid way to read the standard!  You need to understand and read standards better.
You quoted the correct part of the standard regarding this.

The order is implementation dependent means it depends individually on each different browser implementation,
and that different browsers' implementation is SPECIFICALLY ALLOWED to be different.

So despite what existing implementations do, there is NO standard, but rather each implementation is SPECIFICALLY
ALLOWED to be different.

Your summary in @51 is entirely wrong.

Comment 54 by, Mar 22 2011

@krtulmay why are you so angry?

The issue is that the de facto "expected result" differs from the implemented "actual result" as reported by end user developers.

The issue should be addressed.

Comment 55 by, Mar 22 2011

I'm angry that there are some people who actually "expect" any kind of order.  Expecting any order is wrong.
Objects just contain the values; it's just a simple yes or not whether the value is there or not.  There is NO
concept of what order they are in.

The expected result is NO SPECIFIC ORDER, because order is implementation dependent.

As long as the expected result is no specific order, that is any order is possible, then that's fine.

Comment 56 by, Mar 22 2011

@krtulmay I'll say this one last time:

Yes, the order *is* implementation dependent. The expected result is the de facto standard as seen in other production implementations.

Comment 57 by, Mar 22 2011

@nfhm2k, meaning for the last time you are going to show you are not making sense?

Read what you wrote and think carefully:

> The expected result is the de facto standard as seen in other production implementations.
Means the same as:  Order is *not* implementation dependent.  Different ordering implementations do not matter/are not allowed
as there is an expected result.  Which is WRONG!

> The order *is* implementation dependent.  (CORRECT!)
Means the same as:  The expected result NOT defined, SPECIFICALLY ALLOWED to be different, with NO expectation of any order.
This is correct.
@krtulmay: Yor tone does not help your case. You sound like an angry purist
that doesn't have to deal with real life (less professional, as you call it)
web developers. Believe me, I wish JavaScript hadn't been written for

It is obvious that the behavior is not specified. The point is that up until
chrome, all browsers did implement it the same way. Chrome intentionally
implemented it differently waving a flag that says: "I don't care that there
are a lot of programs that depend on this behavior."

Having said all this...

@marclall....: I have never developed a single line of code that depended on
that behavior and I've been coding web pages since 1996. I did notice that
elements were returned in order, but in Rhino, they weren't. That just
didn't sound right. So I looked into the spec, saw that behavior was not
defined and we decided that our company would not write code that depended
on the order of iteration of properties. So I say shame on developers that
relied on non-specified behavior. However, I am not saying that that should
be chrome's attitude.

This has generated enough noise that chrome devs should issue a more
specific explanation as to why the behavior was implemented this way. I
don't think that just because the spec left it undefined is good enough.

Maybe chrome is saying, "It's time for noobs to leave web development" ;)

Comment 59 by, Mar 22 2011

The issue here is not with Chrome the issue is with ECMA who have yet to adopt the de facto standard.

The issue should be raised with them to clarify the standard.
On the contrary.  The issue is very much with Chrome.  Since the spec
doesn't forbid them from implementing it the way some of us want, they are
perfectly free to do it.

If the ECMA clarifies it in our favor, Chrome needs to fix it.  If the ECMA
doesn't clarify it, then we still have to ask why Chrome doesn't choose to
implement this behavior.  Only if the ECMA clarifies the spec, stating that
it isn't implementation dependent or something to forbid order-based
extraction, will Chrome not have to change.

Comment 61 by Deleted ...@, Mar 22 2011

"You sound like an angry purist that doesn't have to deal with real life (less professional, as you call it) web developers."

Experienced web developers should know that in *real life* the order that properties are returned on native objects *is not consistent*, so they do not depend on it (see exmamples provided earlier).

If properties need to be accessed in a defined order, use an index or use a structure that does maintain order (e.g. array, XML).

There is no "defacto standard", Chrome (about 20% marketshare), IE (about 50% marketshare) and Firefox (about 35% marketshare) all have quirks that can result in properties having a different order from each other. So when dealing with arbitrary keys on unknown ojbects in a cross-browser fashion, the order isn't, and never has been, consistent.
The point is that in real life, web developers are not all properly
trained and there are many hackers out there. Like I've mentioned,
I've never checked in a single line of code that depended on that
behavior. However, JS is so easy to get started that anyone thinks
they can code, kind of like PHP. Do we want to break existing code
from developers who were not as careful just to prove a point that
they should have been more careful?

Would a viable alternative be to deprecate the behavior, but maintain
it if the page is in quirks mode?

Comment 63 by, Mar 23 2011

This is not just about punishing amateurs--this is about how standards are created. As we all know, not all standards are set in place in advance by committees. Many, if not most, either follow accepted practice (think HTML5, which formalized what all web browsers were doing anyways), or are never formally defined at all (such as this case). 

Ordered object properties are an extremely useful feature, with no ready and convenient substitute. This is why they are in wide use by developers who never considered the fact that they were depending on an implementation detail. Taking this feature away and breaking existing code for the sake of punishing amateurs or gaining a few percent in some benchmark, or worse of all, to prove some pedantic point, is not an acceptable tradeoff in my opinion. Those arguing otherwise should give some concrete reasons why they think it is.
I spent quite a bit of time last night perusing the following thread:

While I tend to come down on the "I want it" side of the fence, there are
good arguments on both sides.  While no consensus was reached, it appears
the it's still an open issue for ECMA, who will meet on it in a week or two.
 Issue 78039  has been merged into this issue.
Even if not fixing this issue really made Chrome faster, then our applications are slower because we have to implement a way to explicitly sort the object, use the prefix trick or switch to arrays with the amount of work it requires. I do not get the point.

You understand the need to respect the order in arrays, but not in objects. But if you consider that many of us use objects as what is called "associative arrays" in other languages, you should understand better our point of view. It feels so logical for many of us to keep the introduction order, please. Besides, the fix shouldn't break anybody's code, only repair many others' !

I will not fix my applications for Chrome until the point I have no choice.
But thanks anyway for your work besides this big issue.
I was almost done with a statistical system and I try to convince my customer to install and use Chrome in all their 300+ branches, as it is faster than FF... Now I have to hold-on in that thought as my system is showing all the data "ordered" by Chrome and I'm not sure how much time will take me to "fix" my codes.

As evangun2 explained, I guess that most of the PHP programmers (as me) will just use json_encode() with associative arrays and used them directly in Javascript... why? its simple and clean.

Now that Chrome do its way in this matter, I don't know what to say to my customer:
1) Maybe its better to use the slower browser which shows the expected data order
2) I need more resources to "fix" my code

I guess I would have to go with #1... 

Comment 68 by, Jun 2 2011

"I guess that most of the PHP programmers (as me) will just use json_encode() with associative arrays and used them directly in Javascript... why? its simple and clean."

Exactly. No simple alternative exists for this common use case.
For your information, IE9 has adopted the behavior as Chrome. I'm not happy with it but I guess that's not going to change now.
The discussion is closed. We use Firefox, Opera or Safari... but anticipate, yes we can !

Comment 71 by Deleted ...@, Sep 30 2011

why making it simple while we can make it complicate ...
Project Member

Comment 72 by, Oct 13 2012

Labels: Restrict-AddIssueComment-Commit
Owner: ----
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member

Comment 73 by, Mar 10 2013

Labels: -Type-Bug -Area-Compat Type-Compat

Sign in to add a comment