E4X specs states: 13.4.4 ... The XML prototype object is itself an XML object (its [[Class]] property is "text") whose value is the empty string. ... 13.5.4 ... The XMLList prototype object is itself an XMLList object (its [[Class]] property is "XMLList") whose value is the empty XMLList. As such XML.prototype.length() should return 1 while XMLList.prototype.length() should give 0. Yet in SpiderMonkey due to the sharing of prototype object: js> print(XMLList.prototype.length()) print(XMLList.prototype.length()) 1 js> print(XML.prototype.length()) print(XML.prototype.length()) 1 js> XML.prototype === XMLList.prototype XML.prototype === XMLList.prototype true js>

WONTFIX -- the comments in the code allude to ECMA TG1 thinking that XML and XMLList should be unified. SpiderMonkey's unification is intentional. /be

(In reply to comment #1) > WONTFIX -- the comments in the code allude to ECMA TG1 thinking that XML and > XMLList should be unified. The removal of sharing in fact can simplify the complexity of the code from what I observed from a draft patch since GetFunction, http://lxr.mozilla.org/seamonkey/source/js/src/jsxml.c#4025 , becomes just js_GetProperty. On the other hand the implementation would be simplified even father with better error reports if XML_MASK/GENERIC_MASK hack would be replaced by explicit checks in the native methods to apply the current xml-only functions to one-element list. With the current code, for example, XML.prototype.function::setName.call(new XMLList()) would not throw an exception that setName can not be applied to 0-element list. Rather the function silently returns.

Ok, reopen and morph summary slightly ("XML and XMLList prototype sharing complicates code")? /be

And make bug 373072 depend on this one? /be