My favorites | Sign in
Project Home Downloads Wiki Issues Code Search
New issue   Search
for
  Advanced search   Search tips   Subscriptions
Issue 37404: Chrome reorders keys in the dictionary (object) if they can be interpreted as numbers
81 people starred this issue and may be notified of changes. Back to list
Status:  Duplicate
Merged:  issue v8:164
Owner:  ----
Closed:  Oct 2010

Restricted
  • Only users with Commit permission may comment.


Sign in to add a comment
 
Reported by aliaksei.dreamsonic@gmail.com, Mar 4, 2010
Chrome Version       : 4.0.249.89 (38071)
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
     Safari 4: Not tested
  Firefox 3.x: OK
         IE 7: OK
         IE 8: OK

What steps will reproduce the problem?
1. Execute the following javascript code:
	var object = { 3: 3, 2: 2, 1: 1};
	for(var i in object) {
		document.write(i + " ");
	}
2. Notice that the keys are in reverse order.

What is the expected result?
Output: 3 2 1

What happens instead?
Output: 1 2 3

Please provide any additional information below. Attach a screenshot if
possible.

bug.html
146 bytes   View   Download
May 3, 2010
#1 poe...@gmail.com
According to the JavaScript specification, this is not a bug, 
"A for...in loop iterates over the properties of an object in an arbitrary order"
See: 
https://developer.mozilla.org/En/Core_JavaScript_1.5_Reference/Statements/For...in#Desc
ription
May 3, 2010
#2 fabian.j...@googlemail.com
That is true but it does impose an interop problem. Sites, which work in all other browsers can be broken in 
Chrome. I don't think the user cares if it is technically allowed by the spec.
May 3, 2010
#3 tczol...@gmail.com
From the ECMAScript specs:
"The mechanics and order of enumerating the properties (step 6.a in the first 
algorithm, step 7.a in the second) is not specified."

Despite of this above, I think ordering by definition order became a de facto 
standard in all the JavaScript implementation of the ECMAScript, therefore it needs 
to be supported by Chrome.

By the way, this kind of loosely "specified" feature is a bad practise, bad point for 
the ECMA guys out there.
May 4, 2010
#4 bret...@gmail.com
I also heartily hope Chrome will support the de facto standard here. 

However, there are two particular outstanding issues in other implementations which
bear mentioning:

1) iterating over objects on the prototype may not be in the same order (if it is
even clear what order means here anyways); and 

2) More importantly, in trying to mimic ordered associative arrays by using object
literals, in IE, if you delete a property, IE remembers that property's placement
even while removing the value; any subsequent attempt to reset the same property will
put the property back in its original place rather than add it at the end (caused
trouble for our php.js library when we thought we could mimic PHP's very convenient
ordered associative array functions--to define functions which sort an array passed
in place, it would be necessary to delete properties and then add them back in a
different order).

The 1st issue is not so critical, but the 2nd issue does make reliance on this de
facto standard problematic. Nevertheless, I hope Chrome will "fix" it, and hopefully
one day IE can be somehow be persuaded to come around.

While some will say if you want to associate a property with a value and preserve
order, you can just use two arrays wrapped together, or make an array of
single-property objects, this is extremely ugly; for JavaScript to fill its role as
the heir apparent language of convenient ubiquity (lower-case), imo, this is an
absolute must-have. 

Although JSON, as a subset of JavaScript, also defines an object literal as
"unordered", its presence there too is a compelling temptation for devs to depend on
such order; despite protocol, it is just too tempting for people to try to use it
that way, when it mostly does work fine that way.
May 4, 2010
#5 pellicie...@neuf.fr
I guess the navigator Chrome must be like the others.
May 4, 2010
#6 erights@google.com
This looks to me like a duplicate of https://code.google.com/p/v8/issues/detail?id=164 . Until the ES spec is 
changed, I suggest this similarly be closed with a WorkingAsIntended.
May 4, 2010
#7 tczol...@gmail.com
C'mon, you are implementing lots of non-standards just in order to be compatible with 
the major browsers (my first thought is <marqee>, thank god you don't have <blink>), so 
what's the point of NOT supporting something what is not against the standards, what's 
more, complies with a non-written standard?
May 5, 2010
#8 spam...@gmail.com
If you close this as WorkingAsIntended, we will simply open another issue report. I believe this is at least the 4th 
or 5th issue report that web developers have opened regarding this particular bug. This is a serious bug and all of 
the proposed workarounds are ugly.

Programmers are people who don't give up until the job is done right. We will not give up until this is resolved.
May 5, 2010
#9 licordelpolo@gmail.com
Oh my God... b*d developer.... Like as spamfry says... I can open another issue too. 
Tczoltan, I want to see this interesting feature.... BLINK! lol
May 6, 2010
#10 zpu...@gmail.com
I think also it should be fixed, It makes no sense to ignore this since it's a de facto 
standard. Implementing a workaround just for chrome it's not a good solution imho.
May 6, 2010
#11 zeldi...@gmail.com
It's a bit weird that it works in all browsers except Chrome. Should be changed IMO :)
May 11, 2010
#12 teamwen...@gmail.com
This is hilarious. The original thread was started 1.5 years ago by John Resig and its 
still not fixed according to my count. I'm a big fan of chrome but this is too much. 
Fix this so we can all get onto loving chrome again. 
May 13, 2010
#13 teamwen...@gmail.com
I've read several other issues being marked as resolved and working as intended with 
the reason that chrome mimics the behavior of firefox and ie for those instances. This 
is one instance where chrome is breaking my code in a big way and the answer im hearing 
is that the standard is set by someone who apparently doesnt understand conventional 
standards are standards too. I'm going to have to start budgeting time for "chrome 
issues" along side ie. 

Can you feel my frustration?
Jul 16, 2010
#14 maxyma...@gmail.com
This issue has caused more than frustration for me, since I'm using JSON for simple tasks which become a nightmare when using Chrome.
I'm having records pulled out from the database, ordered alphabetically so I can insert them into a dropdown where my users can select them easily since they're ordered alphabetically.
Imagine what happens when you have 20+ dropdowns, each containing 20-100 records and you try to view the page in Chrome and you get a huge mess with finding that exact option you want to select.

Yes, there is a workaround to make all of that work in Chrome but quite honestly - it will save me more time to enforce usage of Firefox or any other browser than to create "fix" in my code so Chrome gets it right.
Jul 27, 2010
#15 efbiaiin...@gmail.com
I also just stumbled onto this bug: my code uses pre-sorted object definition to populate dependent selectboxes and client reported that he is seeing wrong ordering.
My code basically combines values into form: {"firstvalue":{"123":"Abc","11":"Cde"},...}

"firstvalue" represents selected value of the first selectbox and the according object with key=>name mapping is used to fill the dependent selectbox with values and keys are the id values in db, all key=>value pairs are outputted as pre-sorted according to wanted sorting logic. All other major browsers (IE, FF, Safari) loop the object in the order as the properties are defined, Chrome loops the object from smaller key values to bigger values.

Quoting from https://code.google.com/p/chromium/issues/detail?id=883
"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."

Mentioned workaround "add an 'i' or any other non-numerical character in front of each key" is just plain wrong. Instead of fixing it to work like in other browsers and as new ECMAScript defines, it seems Chrome/Chromium is becoming the next IE: reinventing the specs and doing things differently (bad kind differently) than any other major browser out there. Also any comments/thoughts about "you cannot expect insertion ordering from hash list" are all void, since in the other bug someone conveniently pasted in the culprit of this behavior:

  // 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);
  }

Is it possible to get it working like any sane person would expect it to work ? There is no huge refactoring to be done, just delete the "if (name->AsArrayIndex(&index)) {" condition with it's behavior and "if (Handle<String>::cast(key)->AsArrayIndex(&index)) {" part too, recompile, and be done with it.

Right now I'm telling my clients (site is administration of a big e-commerce site and not viewable to public) to use FF, IE or Safari instead of Chrome, since right now, Chrome is the one who's doing things wrong and any possible workaround is just pure ugliness.
Aug 10, 2010
#16 cherra...@gmail.com
I have a big grief with this issue, now that I changed all my code from XML to JSON. I have list of users alphabetically organized coming on a object the property name is the id number that I need to pass back. I have no choice to use a "hack" because the our current architecture.

Here is a simple HTML sample to show the problem:

<html><body><form><select id="jsonRes"></select><select id="nativeRes"></select></form>
<script type="text/javascript">
	if(this.JSON){ 
		var js=JSON.parse('{"300":"A","200":"B","100":"C"}');
		var je=document.getElementById("jsonRes");
	  je.options.length=0;
	  for(i in js){
	      je.options[je.options.length]= new Option(js[i],i,false,false);
	  }
	}
	var nt={"300":"Apple","200":"Bike","100":"Comet"};
	var ne=document.getElementById("nativeRes");
  ne.options.length=0;
  for(i in nt){
      ne.options[ne.options.length]= new Option(nt[i],i,false,false);
  }
</script></body></html>

The "correct" drop lists should show:
Apple
Bike
Comet

The "wrong" list shows:
Comet
Bike
Apple

I have test it with browsers:
FF: correct
Safari: correct
IE8: correct (native only as not JSON is available)
Chrome: wrong
Opera: wrong

I understand that this happens if we are working with Arrays as JavaScript arrays are not defined to be associative indexed, but in this case we are talking about object properties. To be sure also tested the JSON implementation from json.org (and native interpretation if it's available) in other languages.
PHP: ok
Phyton: ok (native ok)
ActionScript: ok (native ok)
Java: ok (native ok)
VBScript: ok
Perl: ok (native ok)
C: ok (native ok)
C++: ok (native ok)
PL/SQL: ok

I could keep testing but the point is that the JSON implementation on Chrome and v8 are broken when this issue is compared with the rest of the world. The exception is Opera that recently got broken also. This shows that is not ECMA's fault, it's how gets implemented. Chrome as Opera are racing in engine optimization but they are dropping the compatibility ball on their way.

I see also the  issue 164  how it has been ignored as WorkAsIntended, this is totally unacceptable, this issue is real and it should work without hacking the indexes. Do we need to start writing hacks ala IE for Chrome on our sites?
Sep 1, 2010
#17 jsa...@gmail.com
Status still unconfirmed ? Seriously :s
Sep 3, 2010
#18 tczol...@gmail.com
I was hoping Chrome 6 fixes this stupid issue. But apparently, Chrome developers want to piss up their poor colleagues :-/ I'm a big fan of Chrome, but it's a huge dislike here.
Sep 3, 2010
#19 cherra...@gmail.com
For 5 months, I used Chrome as my default, now I'm back to Firefox and stop recommending Chrome as a serious viable alternative. I still like most of the things on Chrome, but this kind of attitude really scares anybody trust.

It's OK if they are busy fixing and adding other features, but they should acknowledge the problem. Instead of that I can see the developer team on their status meetings, covering their ears, start singing la-la-la and marking bugs as WorkAsIntended.

By the way, I read the ECMA's documentation about the (for..in). Sure, there is a no reason to get the order of the properties on specific order, but that means that every object will read in a unexpected order. So everybody could move out of this issue.

But more than how the object is read, the problem goes further of how the object is build on the stack on first place, even more specific how the index pointer table is put together. I'm not expert on Javascript engines, but for sure I know how a JVM is build. From a wide overview of the results, it could be that Google is using the same Arrays functions to build Objects. Even for ECMA is trying to avoid confusion between the similar, but not the same, behavior of Arrays and Objects (as it's read on the notes on of the for..in description). 
Oct 14, 2010
#20 stuartmorgan@chromium.org
As mentioned earlier, this is a dup of:
https://code.google.com/p/v8/issues/detail?id=164
Status: Duplicate
Mergedinto: v8:164
Oct 21, 2010
#21 temp01...@gmail.com
 Issue 60113  has been merged into this issue.
Nov 1, 2010
#22 erik.corry
cherrador if you know for sure how a JVM is built then you know the difference between a HashMap and a LinkedHashMap.  JS objects are more like HashMaps in that no guarantees are given about iteration order.  You can build a LinkedHashMap if that's what you want or need.
Sep 11, 2012
#23 akin...@gmail.com
Let's get this fixed... it's 2 years later. SERIOUSLY.
Oct 13, 2012
#24 bugdro...@chromium.org
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.
Labels: Restrict-AddIssueComment-Commit
Mergedinto: v8:164
Mar 10, 2013
#25 bugdro...@chromium.org
(No comment was entered for this change.)
Labels: -Area-Undefined
Sign in to add a comment

Powered by Google Project Hosting