Google Chrome : array evals return out of order

I just want to make others aware of a little quirk with Google Chrome’s Javascript engine (V8), eval’d associative JSON arrays (aka objects) are returned in the incorrect order . The problem is that the engine doesn’t do what a programmer would expect it to do, but the programmer should be aware of why its happening and that it does happen.

Basically, take the following psuedo associative array/object and its corresponding JSON version:

Psuedo Associative array
Array (
 3503 => '',
 3847 => '',
 6852 => ''
);

JSON Array
var data = {3503:'',3847:'',6852:''};

Pretty basic huh? But that happens when we loop over this array/object? In Firefox, Safari and IE we get the same result, which is the array elements in the order listed above. Chrome on the other hand returns the items out of order. Now I know you are probably thinking, “its an array/object, order doesn’t matter”. This is technically true, but not if you are relying on the order for some reason, then you might find bugs cropping up. Check out the code below:

var data = {3503:'',3847:'',6852:''};
var s = '';
for(var i in data) {
	s += i + ',';
}
alert("Expected order: 3503,3847,6852nOrder observed: " + s)

Firefox, Safari and IE all return the following alert:

Expected order: 3503,3847,6852
Order observed: 3503,3847,6852

Chrome on the other hand returns this:

Expected order: 3503,3847,6852
Order observed: 6852,3503,3847


Weird! Give it a try in your current browser by clicking here

Javascript guru, John Resig, has posted a note about this:
http://ejohn.org/blog/javascript-in-chrome/

Or for the official bug reports:
http://code.google.com/p/v8/issues/detail?id=6
http://code.google.com/p/chromium/issues/detail?id=883

As always with javascript programming, expect the unexpected… and…
Be Warned!

Trac ticket: reset to new

We have recently moved from Mantis to Trac at work for our bug/task tracking, but we have encountered a slight issue with Trac’s workflow management. The issue is that we wanted to be able to move a ticket from the ‘assigned’ state to the ‘new’ state. This is a common scenario if a team member leaves or goes on holiday while they have tasks assigned to them. Quite often you wouldn’t just want to blindly ‘reassign’ these issues to another member, but reset them to their new status so another member can pick the task up when they have the time.

We decided to introduce a new state called ‘reset’ in the trac.ini [ticket-workflow] block which allows us to easily reset a ticket to the ‘new’ status as if it had just been created in the system. The new block looks like this:

reset = * -> new
reset.operations = del_resolution
reset.permissions = TICKET_MODIFY

Now at the bottom of each ticket, we have an option which says:

[ ] reset  Next status will be 'new'

Hope this works for you too :)