The dev console fails to display array-like objects correctly when they use get/set methods on their indexers!

1,630 views
Skip to first unread message

ryanth...@gmail.com

unread,
Jul 4, 2012, 1:52:55 PM7/4/12
to google-chrome-...@googlegroups.com
Hi Google Developers,

This might be the wrong place to post my question, but it feels like the right place, please let me know if it's not!

Part of the ECMA standard I believe is that Javascript consoles will display objects as arrays when the objects are array-like.

Such as: ["hello", "world"] for an object containing strings that are numerically indexed.

Array-like behaviour is defined as a length property and a splice method being present on the object, as well as numerically indexed properties.

Libraries like jQuery do exactly this.

I've been trying to take advantage of this behaviour and consider it desirable. However I have the additional requirement that my indexes use getters/setters to set them so that I can do some additional processing when they're modified.

However when I do this the above array is instead rendered as:

[undefined × 2]

However the object behaves otherwise exactly the same as a simple example.

See this Fiddle for a far better explanation: http://jsfiddle.net/5YgAv/

So you see? Two very similar examples, however the presence of the getter has broken it in the console.

I've been debugging the latest Chromium dev tools and it appears that Chrome pushes a message at the console which essentially contains the getter function. However there's no way to modify the console source code so that it can invoke the function and get the value. If that were possible then we could modify the developer tools to handle getters and setters correctly.

What I'd like to know is if anyone has any insight into this interesting little bug or how it might be best fixed before I file it as a bug to be possibly long forgotten!

I'd like to fix it myself, but I'm not familiar with the high level architecture of Chrome so would appreciate some pointers on where it should be fixed?

I'm also open to a workaround that's elegant and allows me to do some special processing when any of the properties on my array-like object are modified.

So... Over to you guys....

[Ryan]

PhistucK

unread,
Jul 5, 2012, 2:11:14 AM7/5/12
to ryanth...@gmail.com, google-chrome-...@googlegroups.com
I would say that this is working as intended, but Chrome engineers know better and I hope they will chime in.

It works as intended, in my opinion, because abnormal numerically indexed properties like the ones you mentioned (with getters) can have side effects when getting their values (due to the getters). If the console had called those getters, unintended side effects could have been triggered just because you expanded an object within the console.

PhistucK

Ryan Worsley

unread,
Jul 5, 2012, 2:28:05 AM7/5/12
to PhistucK, google-chrome-...@googlegroups.com
I'd thought this myself!  I hope they chime in here too so I can put this to rest.

I really want the array-like behaviour, but I do need to do some additional processing when performing a set - not when performing a get.

Do you have any suggestions perhaps how to solve the initial requirement?  I basically want to perform some processing when a property is set and be able to see array-like behaviour in the console.

Pavel Feldman

unread,
Jul 5, 2012, 2:44:47 AM7/5/12
to PhistucK, ryanth...@gmail.com, google-chrome-...@googlegroups.com
>> Part of the ECMA standard I believe is that Javascript consoles will display objects as arrays when the objects are array-like.

Could you point me to this part of ECMA? I did not know ECMA was aware of "console" object.

>> What I'd like to know is if anyone has any insight into this interesting little bug or how it might be best fixed before I file it as a bug to be possibly long forgotten!

It is only forgotten if its priority is very low. In this case, it is likely to be so though.

>> I'd like to fix it myself, but I'm not familiar with the high level architecture of Chrome so would appreciate some pointers on where it should be fixed?

Looking at the InjectedScriptSource.js and building Chromium with its modified versions it the right way to go. Filing a bug using webkit.org/new-inspector-bug and moving this discussion there is the right next step.

Regards
Pavel

Ryan Worsley

unread,
Jul 5, 2012, 5:11:18 AM7/5/12
to Pavel Feldman, PhistucK, google-chrome-...@googlegroups.com
Thanks a lot!
Reply all
Reply to author
Forward
0 new messages