firefox dom/xml serialization/deserialization bug

[guest]

I recently detected a bug in mozilla's/firefox dom/xml serialization/deserialization, that could effect the dojo framework - I actually found 5 occurances in the dojo package where mozilla's / firefox 's XMLSerializer.serializeToString method is used that could result in unexpected behaviour, if the serialized string is used to set the "innerHTML" attribute of a dom node. I did not follow up each and every piece of the dojo code to see if this bug actually is causing a problem, but I felt that possibly many users should be aware of this bug to avoid/work around it in their own script implementations.

I detected that this bug comes into play with the dojo.xml.XlsTransform? package.

I already posted this bug along with a test case and a possible resolution under ​http://www.formassembly.com/forums/viewtopic.php?t=523

Here is what goes wrong :

• a common coding approach is to render the result of a xslt-transformation by serializing it using the firefox built-in XMLSerializer and then apply it to the "innerHTML" attribute of a dom node
• unfortunately, in case of empty elements, the built-in XMLSerializer of firefox uses the none-w3c-compliant short syntax ( e.g. <tag .../> ) instead of explicitly closing each tag (e.g. <tag ...></tag>)
• if applying the output of XMLSerializer to the "innerHTML" attribute this results in empty elements being nested instead of being on the same tree-level (see my test case following the link mentioned above), due to the fact that the short syntax to close a <tag> is not correctly handled by the firefox xml parser
• a possible resolution to this would be not to serialize the transformation result and apply it via "innerHTML", but to simply append/replace it via a simple dom operation (see my test case following the link mentioned above)

Hope that some of you find this interesting and helpful - at least I did not expect such a major bug in mozilla/firefox and I think everyone agrees that a string serialization of a xml/dome node being deserialized again should create the same object as before.

Thanks.

[Adam Peller]

I don't think this is relevant to 0.9?

[Tom Trenka]

Nope.

[Tom Trenka]

Need to find out if the same serialization bugs are present in Firefox 3; deferring with the rest of the XSLT tickets.

[Tom Trenka]

Some triage, closing old tickets that seem no longer relevant.