W3C home > Mailing lists > Public > public-html@w3.org > June 2012

Handling of objects with both named and indexed properties is probably incorrect

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Fri, 15 Jun 2012 13:45:56 -0400
Message-ID: <4FDB74D4.7090001@mit.edu>
To: public-script-coord@w3.org, HTML WG <public-html@w3.org>
Consider this testcase:

   <!DOCTYPE html>
   <form><input name="1"></form>
     var list = document.forms[0].elements;

Browsers mostly interoperably alert "undefined" (well, at least Gecko, 
WebKit+V8, Presto, Trident all do; WebKit+JSC alerts "[object 

However the current WebIDL spec plus the current HTML spec seem to 
require that "[object HTMLInputElement]" be alerted.  Indeed in WebIDL 
section 4.6.2 step 1 substep 2, ToUint32("1") is not a supported 
property index, so we move on to step 2.  form.elements supports named 
properties, so step 2 involves us calling the named property getter, and 
the HTML spec says the set of supported property names is "all the id 
and name attributes of all the elements represented by the collection".

I think that Safari's behavior here is buggy; in particular it would 
break loops of the form:

   for (var i = 0; list[i]; ++i) {

which are in fact used in the wild (though possibly not on nodes with 
ids that look like integers).

If the specs want to align with the non-Safari behavior, I think there 
are two options.  Either HTML needs to exclude ids and names that look 
like integers from the set of supported property names, or WebIDL needs 
to be changed so that for objects which support indexed properties step 
2 of 4.6.2 is skipped if the given property name is an array index 
property name.

Personally, I would prefer this be changed in WebIDL.

Received on Friday, 15 June 2012 17:46:25 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:53 UTC