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 18 users

Issue metadata

Status: Fixed
Owner:
Last visit > 30 days ago
Closed: Oct 2008
HW: ----
NextAction: ----
OS: ----
Priority: 1
Type: Bug



Sign in to add a comment

Chrome/V8 breaks Prototype JavaScript library

Reported by aarons...@gmail.com, Sep 3 2008 Back to list

Issue description

In Chrome, if you do a $(element).select(...), any elements returned aren't
prototype-ified... even after you $() them.

This works in all major browsers except Chrome.
 
After doing Element.extend(elm), elm.identify() returns the error "TypeError: Object 
[object HTMLDivElement] has no method 'identify'"
Looks like Prototype isn't alone. jQuery is having problems too:

http://groups.google.com/group/jquery-en/browse_thread/thread/658db22dc3dc840b

I found a problem that seams related. Check the following code:

var id = document.getElementById("someid");
var f = function(){};
id.onclick = f;

for(var a in id){
  if(a === f){ console.log("match"); };
}

Event handlers seam to get ignored by the for...in-operator. Anything else will be 
there. They further don't show up in the JavaScript console. If you use the delete 
operator on a event handler you will get a mess.
Looks like the problem was fixed:

http://code.google.com/p/chromium/issues/detail?id=131#c5

Labels: Type-Bug Priority-Medium
Status: Assigned
Thanks for bringing this issue to our attention. I'll look into the Prototype and 
jQuery issues and expect to have an update or a fix shortly. If anyone has a reduced 
test case that would be a great starting point.

Comment 6 by feng@chromium.org, Sep 4 2008

I bet it is a different issue from http://code.google.com/p/chromium/issues/detail?id=131#c5
That bug happens in if (negative integer in array)

This bug is about some dom properties not show in for-in loops.
DOM event handlers are handled differently in the DOM binding part.

Comment 7 by feng@chromium.org, Sep 4 2008

From the discussion, two failed tests are:
1) parsing escaped strings, that looks like a bug in v8 parser;
2) it expects for (j in a) returns j in the same order as properties were put in a.
In ECMA-262, section 12.6.4, the first paragraph after description of the semantics:
The mechanics of enumerating the properties (step 5 ...) is implementation dependent. 
The order of enumeration is defined by the object.

For non-numerical property names, V8 actually enumerates properties in the order when 
they were added. But there is no guarantee of numerical property names. 

Comment 8 by feng@chromium.org, Sep 4 2008

Ok, I looked at jQuery source, it looks like a WebKit bug when escaping code.
	equals( jQuery("#foo").text("<div><b>Hello</b> cruel 
world!</div>")[0].innerHTML, "&lt;div&gt;&lt;b&gt;Hello&lt;/b&gt; cruel 
world!&lt;/div&gt;", "Check escaped text" );

The same test fails in Safari 3.1.2 on Windows, with the same result.

Comment 9 by feng@chromium.org, Sep 4 2008

Looks like WebKit nightly fixed HTML escaping issue. The test passes in Safari 
nightly r36012. Chrome should get it after next WebKit merge.

Comment 10 by feng@chromium.org, Sep 4 2008

The second one 'for-in' is a bug in V8:

var x = [a : 1, b :2];
for (p in x) print(p);

It prints out 'b' before 'a'.

var x = {};
x.a = 1;
x.b = 2;
for (p in x) print(p);

it prints out 'a' before 'b';

I will take a look at the code.


Comment 11 by feng@chromium.org, Sep 4 2008

Another user reported for-in order of arrays.
---
var a = [];
a[1100] = [1];
a[1150] = [0,1];
a[1230] = [0];

var s = '';
for(p in a) s += p + ':' + a[p] + '\n';
alert(s);
---
In all those browsers except Chrome, I got the following output:
---
1100:1
1150:0,1
1230:0
---
In Chrome, I got this:
---
1230:0
1100:1
1150:0,1

---
var a = [];
a[2] = 'A';
a[1] = 'B';
a[0] = 'C';
---
Every browser except Chrome produced the following output, once again
in order of element creation:
---
2:A
1:B
0:C
---
Chrome, on the other hand, produced this:
---
0:C
1:B
2:A
---

var x = [a : 1, b :2];

That's not valid JavaScript code, so it shouldn't work at all.

For the others, as you mentioned in comment 7, the order of enumeration of object
properties is implementation dependent. This is also the case when the object you're
enumerating is an array. No one should ever use a for..in loop on an array anyway.

Comment 13 by feng@chromium.org, Sep 5 2008

The second issue should be fixed in r147

Comment 14 by feng@chromium.org, Sep 6 2008

I just verified in my local build of test_shell with latest V8 that the second 
failure is fixed.

Kasper, can I take this bug away from you?
Yes, of course Feng. The bug is all yours. Thanks for looking into this issue.

Comment 16 by feng@chromium.org, Sep 8 2008

Status: Fixed
The second jQuery issue was fixed. The first jQuery issue is fixed in WebKit trunk, 
and Chrome should pick it up in the next merge.

I didn't hear anything from Prototype, and I am going to mark this bug as fixed.
If the Prototype library is still broken, please file a new bug with either a reduced 
test case, or some links to demonstrate the failure.
@ Comment 12:
"No one should ever use a for..in loop on an array anyway."

How else should I iterate over all and only the elements in a sparse array?

Comment 18 by feng@chromium.org, Sep 8 2008

You can use for .. in on objects, but the order is not guaranteed. It is part of the 
spec. However, in practice, every browser enumerates properties in the adding order, 
exception when you do 'deletion', 'insertion', etc. V8 tries to behave the same in 
common simple case.

Comment 19 by feng@chromium.org, Sep 14 2008

Status: Accepted
Re-open the bug since it was reported that Chrome does not pass all YUI and Prototype/script.aculo.us tests.
http://developer.yahoo.com/yui/
http://script.aculo.us/
http://www.prototypejs.org/


Comment 21 by san...@gmail.com, Oct 7 2008

Has this Bug something to do with the chromium  bug 1058 ?
http://code.google.com/p/chromium/issues/detail?id=1058

Comment 22 by feng@chromium.org, Oct 7 2008

It could be. Mads, can you verify if your fix of chromium  issue 1058  fixes YUI tests?

Comment 23 by ager@chromium.org, Oct 7 2008

Status: Fixed
I have downloaded YUI 2.6.0 and used the yui/tests/YUI.html page to run the tests.  I
see the same amount of passed and failed tests on Safari 3.1.2 for Windows, Firefox
3.0.3 and tip of tree Chromium.

Anyway, the fix for chromium  issue 1058  does not seem to affect YUI.

This issue has turned into a meta issue.  It seems to me that most (if not all) of
the problems have been resolved.  If anyone knows of prototype/yui/jQuery issues that
have not been resolved, please file new bugs.
Both Chrome 2 and 3 fails my enumeration tests in 
http://github.com/dotnetCarpenter/hdStore/ while all other browsers pass (IE6-8, 
Opera 9-10, Firefox 3-3.5, Safari 3-4).

I'm having trouble pin pointing the exact place where Chrome differs though, making 
it hard to provide a simplified test case, other than object properties seems to be 
sorted when I look in the JavaScript console.

Due to the ECMA-262 specs as noted in comment 7 this doesn't have to be considered a 
bug. IMHO being the "only" browser that differs constitute a bug.
dotnetCarpenter-hdStore-4ae6eed775b89087cb1232d7e6c54f99632a3931.zip
39.1 KB Download
Labels: Priority-1

Sign in to add a comment