[HAS-REDUCTION] This is a known issue. 

0 bytes Download

883.html 456 bytes View Download

Reduction can be accessed by http://go/reductions/883/test-quirks.html

Looks like this got fixed. Both the website and reduction show expected behavior. Google Chrome	0.3.154.9 (Official Build 4058)

Did you mean Status: Fixed?

Tested with Google Chrome 0.3.154.9 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.

chrome.html 410 bytes View Download

[Confirmed]

The chrome.html still shows error with Chrome 0.4.154.18 (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.

Guys this is not a bug.
http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-357.pdf
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.

@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.

@jeresig

John,
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!

"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? 

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

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".

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

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 for..in will
not return the order the elements are defined?

...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.

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.

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.

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.

Hello folks,

I've opened another issue for this bug (as this is still a problem and is
inexplicably closed as wontfix): http://code.google.com/p/chromium/issues/detail?id=20144

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^^

PropertyMapHashTable.h 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 runtime.cc. 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);
      key_string->TryFlattenIfNotFlat();
      result = SetProperty(js_object, key_string, value, attr);
    }
    if (result.is_null()) return Failure::Exception();
    return *value;
  }

Keep up the good work!

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 http://www.ecmascript.org/docs/tc39-2009-043.pdf
on the for...in loop, "The mechanics and order of enumerating the properties...is not
specified".  

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

If it is true that "order of iteration" is the "order of insertion", being within
for...in 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 for...in 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) {
    keys.push(p);
    vals.push(obj[p]);
    delete obj[p];
  }
  keys.reverse();
  vals.reverse();
  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.

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:
<script>
	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;
	};
</script>

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.

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 
there:
http://code.google.com/p/chromium/issues/detail?id=37404

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... :)

Still not fixed in Chrome 6. 
http://jsfiddle.net/kolor/Nt39S/

Hello.
What is the official word on this?

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.

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

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.!!!

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

See issue #72652

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.

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.

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

The de facto/expected behaviour should be used.

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.

"The order in which item is bound to members of collection is implementation dependent." - http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-357.pdf

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

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.

@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.

@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.

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.

@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.

@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
non-programmers.

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" ;)

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.

@mendesjuan
"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?

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:

https://mail.mozilla.org/pipermail/es-discuss/2011-March/012965.html

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... 

"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 !

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

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.