Opened 15 years ago
Closed 12 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 )
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 15 years ago by
Owner: | changed from anonymous to Tom Trenka |
---|
comment:3 Changed 14 years ago by
Milestone: | → 1.3 |
---|
comment:4 Changed 14 years ago by
Description: | modified (diff) |
---|---|
Milestone: | 1.3 → future |
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 12 years ago by
Status: | new → closed |
---|
Some triage, closing old tickets that seem no longer relevant.
I don't think this is relevant to 0.9?