Opened 12 years ago

Closed 9 years ago

#2380 closed defect

firefox dom/xml serialization/deserialization bug

Reported by: guest Owned by: Tom Trenka
Priority: high Milestone: future
Component: Dojox Version: 0.4.1
Keywords: firefox xml parser Cc:
Blocked By: Blocking:

Description (last modified by Tom Trenka)

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.

Change History (5)

comment:1 Changed 12 years ago by Adam Peller

Owner: changed from anonymous to Tom Trenka

I don't think this is relevant to 0.9?

comment:2 Changed 12 years ago by Tom Trenka

Component: GeneralDojox

Nope.

comment:3 Changed 11 years ago by dylan

Milestone: 1.3

comment:4 Changed 11 years ago by Tom Trenka

Description: modified (diff)
Milestone: 1.3future

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

comment:5 Changed 9 years ago by Tom Trenka

Status: newclosed

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

Note: See TracTickets for help on using tickets.