Consider the following code that compares XML versus the legacy flash.xml.XMLDocument: var s:String = "<somexml>and</somexml>"; var xml:XML = <soap></soap>; xml.appendChild(s); trace("E4X Result: " + xml.toXMLString()); var xmlDoc:XMLDocument = new XMLDocument("<soap></soap>"); var node:XMLNode = xmlDoc.firstChild; var stringNode:XMLNode = xmlDoc.createTextNode(s); node.appendChild(stringNode); trace("\nLegacy Result: " + xmlDoc.toString()); Actual Results: ------------------------------------------------ E4X Result: <soap> <somexml>and</somexml> </soap> Legacy Result: <soap>&amp;lt;somexml&amp;gt;and&amp;lt;/somexml&amp;gt;</soap> ------------------------------------------------ Notice the E4X case, when converted into a String via toXMLString() now has the String content appearing as if it were part of the XML document where in fact it should have been escaped on being set as content on the <soap> node. The E4X specification is not that easy to follow, but the following syntax semantics for XML element content stipulate if the value is not an XML or XMLList then it is converted to a String and then escaped as defined in section 10.2.1.1. "The production XMLElementContent : { Expression } XMLElementContentopt is evaluated as follows: 1. Let expRef be the result of evaluating Expression 2. Let expression = GetValue(expRef) 3. If Type(expression) ∈ {XML, XMLList}, a. Let value be the result of calling ToXMLString(expression) 4. Else a. Let value be the result of calling EscapeElementValue(ToString(expression)) 5. Let content be the result of evaluating XMLElementContentopt; if not present, use the empty string 6. Return the result of concatenating value followed by content"

Bug transferred from bugbase: 206157 Jim Corbett has a fix now that version checking is implemented in the avm.

logged bug 523823, to add shell flag so we can set the version to regression test both the old behavior and the fixed behavior in the acceptance tests.

Bug depends on 523823 in order to generate test media.

Is this actually fixed? Can this be confirmed again? I thought that there was NO incompatible changes until we have a dot release

(In reply to comment #4) > Is this actually fixed? Can this be confirmed again? I thought that there was > NO incompatible changes until we have a dot release Ah, reading again this is comparing E4X to old XMLDocument.

The fix for bug 535770 reopened this in a subtle way: we weren't correctly fixing this in the SWF10/SWF11 case, and I didn't notice it because the relevant acceptance tests weren't adjusted for both old and new cases.

The code in XMLObject was less than clear, in that the wording led me to an additional negative where none was appropriate, with the result that we always did SWF9 behavior regardless of whether the flag was set correctly or not. Restructured the code to deal with this, and adapted the relevant testcases to look for the proper result based on System.bugcompat.

Comment on attachment 465380 [details] [diff] [review] Patch http://hg.mozilla.org/tamarin-redux/rev/3ab8a354fd46

(please push along with the other patch)

Comment on attachment 465803 [details] [diff] [review] add USE_BUGCOMPAT usage to testcases for 444630 Review not needed as files were already pushed: http://hg.mozilla.org/tamarin-redux/rev/74a610f7165a then updated: http://hg.mozilla.org/tamarin-redux/rev/41ee7ef53bab