Closed Bug 398272 Opened 17 years ago Closed 6 years ago

Unable to round-trip tab character using XMLHttpRequest and XMLSerializer


(Core :: XML, defect)

Not set





(Reporter: bugs, Assigned: hsivonen)





(2 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv: Gecko/20070914 Firefox/
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv: Gecko/20070914 Firefox/

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 "	", 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:

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
Attached file Test Case
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 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.
Attached file test case
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 fails with both Firefox 3.6 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: 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).
Ever confirmed: true
I tried the test case 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:
Any update on this? 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)

Resolving INVALID in the sense that the allegation of behavior is correct, but the behavior is according to spec:

Changes should be discussed as spec changes but I doubt any engine is keen to change anything here.
Closed: 6 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.