effect of ECMA-357, specifically x.namespaceDeclarations() should not include
the default namespace inherited from the <parent> tag wrapped around a string
argument "<x>...</x>" by ToXML, whereas x.inScopeNamespaces() should.
This case implies errata against 10.3.1, 10.4.1, and 13.4.4.24 (at least).
- Consolidate common code in an XMLArrayInsert function, renaming the misnamed
precursor to XMLArrayAddMember. XMLArrayInsert properly notifies any cursors
iterating over the array, fixing for/in and for-each/in bugs such as this:
var l = <><a/><c/><d/></>;
var i = 0;
for each (var x in l) {
print(x.toXMLString());
if (i == 1) l[0] += <b/>;
i++;
}
- Fix the bug induced by this erratum from ECMA-357:
9.2.1.2 step 2(c)(ii) sets _y.[[Parent]] = r_ where _r_ is the result of
[[ResolveValue]] called on _x.[[TargetObject]] in 2(a)(i). This can
result in text parenting text:
var MYXML = new XML();
MYXML.appendChild(new XML("<TEAM>Giants</TEAM>"));
(testcase from Werner Sharp <wsharp@macromedia.com>).
To match insertChildAfter, insertChildBefore, prependChild, and
setChildren, we should silently do nothing in this case.
- Fix PN2X_OUTERMOST not to overlay XSF_CACHE_VALID, causing it to appear to be
set when cx->xmlSettingFlags were "translated" into ParseNodeToXML flags. To
avoid further such stupidity, consolidated all similar flags into XSF_* bits
and eliminated the PN2X_* duals.
- Redo the way the default namespace is inherited by parsed XML from the
<parent> tag under ToXML and ToXMLList, and implicitly inherited in the
js_ParseNodeToXMLObject alternative path to ToXML.
- Handle null prefix (meaning undefined in ECMA-357, that is, no prefix was
passed to the Namespace constructor) and empty prefix (which is normalized
from null for the empty URI "no namespace" case) better in the parsing and
ToXMLString code.
- Fixed a bug in PutProperty where it implements 9.2.1.2 2(c)(vii)(1) (whew!).
Fixed another bug near that which stupidly assumed all XML nodes have names,
leading to an obvious null pointer crash.
This should be the final round of work for bug 246411. With the appropriate
testsuite patches, this passes all tests except e4x/Regress/regress-264369.js
(which probably should be invalidated by a correction to the ECMA-357 spec).
Rhino never claimed to support binary compatibility in the serialized objects and it is better to use the system generated ids always to catch errors about incompatible changes ASAP.
brendan%mozilla.org
bryner%brianryner.com
bsmedberg%covad.net
igor%mir2.org
bmlk%gmx.de
shaver%mozilla.org
timeless%mozdev.org
nboyd%atg.com
gerv%gerv.net
darin%meer.net
vladimir%pobox.com