User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:22.214.171.124) Gecko/20070914 Firefox/126.96.36.199 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:188.8.131.52) Gecko/20070914 Firefox/184.108.40.206 Unable to save values with character entities using XMLSerializer. It properly escapes values such as '&', replacing it with "&", but doesn't replace a tab character ('/t') with "	". Trying to save "	" results in the entity being escaped as "&#09;", which should be expected. Either additional characters such as '/t' should also be escaped, or there should be additional options for controlling character entities. (I just verified that using Apache Xalan-J (the default JAXP transformer under Java 6) serializes '/t' using a character entity.) This may very well affect other characters besides the tab ('/t') character. Reproducible: Always Steps to Reproduce: Use case: 1) Create or open a new XML document for modification using DOM. 2) Set an XML attribute value containing a tab character. e.g., node.setAttribute("someName", "some /t Value"); 3) Save the XML using XMLSerializer. 4) Re-read the XML using XMLHttpRequest. Actual Results: This is read back in as "some Value" instead of "some /t Value". Verified that the saved XML contains 13 characters, including [space,tab,space]. Expected Results: The "someName" attribute should be read back in as "some /t Value". Missing the tab when reading this is somewhat expected, per what I understand of the W3C specification regarding attribute normalization: http://www.w3.org/TR/2000/REC-xml-20001006#sec-white-space When manually changing the saved XML to instead use a character entity ("some 	 Value"), the read from XMLHttpRequest works as desired, returning "some /t Value" for the "someName" attribute. Further discussion at http://groups.google.com/group/mozilla.dev.tech.xml/browse_thread/thread/c0ad1ff4066d23fe
I came across a very similar situation myself and created this test case for it. The details are not exactly the same. My test case uses DOMParser.parseFromString to read in some xml, rather than serializing and re-reading the string. However, the general jist is the same. Attributes containing literal tab characters are having those tab characters collapsed.
It's been over a year. Can the status on this please at least be updated past "unconfirmed"? As Chris noted in comment #1, and as listed on the mozilla.dev.tech.xml group (linked above), I'd consider it to be a confirmed issue...
I am facing the same problem, both for tabs and for new lines. Why is this bug so impopular? It seems very silly that Firefox cannot support AJAX applications properly.
Test case whether parsing attribute value with numeric character references of ' ' and '	' with DOMParser, then serializing with XMLSerializer, then parsing again with DOMParser round-trips the attribute value.
Confirming bug: test case https://bug398272.bugzilla.mozilla.org/attachment.cgi?id=508260 fails with both Firefox 3.6 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:220.127.116.11) Gecko/20101203 Firefox/3.6.13) as well as 4.0 nightly (Mozilla/5.0 (Windows NT 5.1; rv:2.0b11pre) Gecko/20110130 Firefox/4.0b11pre).
Status: UNCONFIRMED → NEW
Ever confirmed: true
See also: <http://www.w3.org/TR/xslt-xquery-serialization/>.
I tried the test case https://bug398272.bugzilla.mozilla.org/attachment.cgi?id=508260 with Opera 11 and with IE 9 Beta on Windows and they both pass the test, meaning their XMLSerializer implementations ensure that the characters LF and TAB inside of attribute values are serialized as character references.
Henri, is this something you'd be interested in looking at?
Assignee: nobody → hsivonen
(In reply to comment #8) > Henri, is this something you'd be interested in looking at? Yes. (Looks like I really should write a spec for XMLSerializer, too.)
(In reply to comment #9) > (Looks like I really should write a spec for XMLSerializer, too.) Actually, Ms2ger is already on the case: http://html5.org/specs/dom-parsing.html#the-xmlserializer-interface
Any update on this? https://bug398272.bugzilla.mozilla.org/attachment.cgi?id=508260 is still failing under Firefox 7.0.1. With the rate of new releases now, maybe this can be fixed for Firefox 8, 9, or 10? :-)
When will this be fixed? Still fails in FF16.0a1 (2012-07-16) Thanks, Peter
Resolving INVALID in the sense that the allegation of behavior is correct, but the behavior is according to spec: https://w3c.github.io/DOM-Parsing/#dfn-serializing-an-attribute-value Changes should be discussed as spec changes but I doubt any engine is keen to change anything here.
Status: NEW → RESOLVED
Closed: 9 months ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.