Re: DOM collections index out of bounds and JavaScript.

On 10/18/10, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 10/18/10 8:51 PM, Erik Arvidsson wrote:
>> When DOM was first spec'ed the collection interfaces all had some kind
>> of item method. These methods sometimes return like null[1] and
>> sometimes other values such as an empty string [2]. The JavaScript
>> bindings for these allows us to use indexed getters instead of calling
>> the item method.
>
> I think in practice this has been a fiction in the edge case you're
> interested in.
>
>> The problem is that trying to get a non existing property in JS should
>> return undefined.
>
> This is what UAs implement, yes (modulo bugs).
>

That is mostly true. Though with IE errors, there is evidence there of
catchall/proxy at hand. I recall Opera also has observable catchall or
"proxy" for get access on certain collection objects to return "null"
(looking for Opera on this computer...)

Opera 10.5:
document.styleSheets[99] === null
- yet -
document.childNodes[99] === undefined.

Obviously since [[Get]] access on styleSheets collection returns null,
it is not a [[Get]] as defined for native ES objects and so it can
only be explained by a specialized [[Get]] on that object. AIUI ES
committee is calling this "forwarded get access" on proxies now
(though I've not been following that closely.).

>> Since we are
>> trying to realign these specs with the web it would make sense to try
>> to make them fit better with JavaScript and mandate that the JS
>> bindings for collections should return undefined for getting an item
>> out of bounds.
>

That makes sense, as otherwise there would be a catchall at hand. And
that brings us to the next issue:

> This has nontrivial compat risks, I suspect.  I've seen code that
> compares the return value of item() to null using ===...
>
> I agree that using the [] notation should return undefined for
> out-of-bounds stuff; I'm pretty sure the indexgetter stuff already says so.
>

The risk in changing "item" and property access to return undefined is
that of strict equality checks, e.g.

if (ob.item(n) === null)

Loose equality checks will ahve the same result, as null == undefined, e.g.

if (ob.item(n) == null)

FWICT, it doesnt seem like a serious impact:
http://www.google.com/codesearch?hl=en&lr=&q=\.item\%28\d%2B\s*\%29\s*%3D%3D%3D\s*null+lang%3Ajavascript&sbtn=Search

Though please consider that I've missed something and double check my regexp:

\.item\(\d+\s*\)\s*===\s*null lang:javascript

Garrett

Received on Tuesday, 19 October 2010 01:35:05 UTC