Created attachment 658679 [details] Reporter's testcase In previous versions of Firefox, the result was: <val pilou="<toto>&" attr="<popo"></val> (that's pretty similar to: <val attr="<popo" pilou="<toto>&"></val> (inversed parts) Now since FF15, the result is: <val pilou="<toto>&" attr="<popo"></val> Regression range: m-c good=2012-06-01 bad=2012-06-02 http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=73783bf75c4c&tochange=5199196b65ec m-i good=2012-06-01 bad=2012-06-02 http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=50c9995aa7d0&tochange=9abc60f44fd5 It needs more investigation.
while this is a recent regression , is this a critical user facing issue ?
I think that it can broke compatibility with some services. In my case, I send with ajax a xml file to a php file. With this issue, php can't parse my xml file as it said it's not valid xml. Fortunately it's not common to have special characters in xml attribute, but still it can happen ... as it happen to me.
CCing Cheng, Matt, and Tyler - are we getting much report about this in SUMO or input that would suggest this is something to do another respin of mobile 15 for? I suspect it's not, and we can wait to investigate this for Beta/Aurora - but would like confirmation.
I did some digging on input and it seems to be fairly isolated. I haven't seen anything on SUMO. My instincts say we can wait. I'll do some more digging on Monday to see if the landscape changes.
Can we get a bisection here and figure out what bug caused this?
I confirm the results in comment 1 on Win 7 x64 on FF 15.0.1 and 16b2. Dropping qawanted since there is already a reproducible testcase for this bug.
Regression window(m-c) Good: http://hg.mozilla.org/mozilla-central/rev/cb648ec7d7f2 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/15.0 Firefox/15.0a1 ID:20120601025002 Bad: http://hg.mozilla.org/mozilla-central/rev/7bf0125b26b5 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/15.0 Firefox/15.0a1 ID:20120601035703 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=cb648ec7d7f2&tochange=7bf0125b26b5 Triggered by: Bug 744830
There is no XML anywhere here. JQuery's $() just parses things as HTML in the context of the current HTML document. So the testcase is producing an HTML fragment, then serializing it using innerHTML. That should run http://www.whatwg.org/specs/web-apps/current-work/multipage/the-end.html#html-fragment-serialization-algorithm which says: For each attribute that the element has ... the attribute's value, escaped as described below in attribute mode which links to http://www.whatwg.org/specs/web-apps/current-work/multipage/the-end.html#escapingString which says that '<' and '>' are only escaped NOT in attribute mode. So the new behavior is the one the spec calls for. It's also the behavior that Opera has. WebKit does escape the '<' and '>' when getting innerHTML. It's worth looking into whether the spec needs changing here, I guess. But Mathieu, you are NOT serializing things as XML here, so any ability you had to pass the result to an XML parser was a complete accident.
What does IE do?
IE seems to work like Gecko and Presto, and they all do what the spec says. Webkit does something different.
IE10, maybe but not IE9: <val attr="<popo" pilou="<toto>&"></val>
That is just different order of attributes, not different handling for < and >, which this bug is about.