Last modified: 2014-03-11 02:05:17 UTC
This test works in Chrome, but in Firefox it fails with: Expected: "a<b>b<span typeof=\"mw:Entity\" class=\"ve-ce-leafNode ve-ce-MWEntityNode\" contenteditable=\"false\">c</span>d<div class=\"ve-ce-leafNode ve-ce-alienNode ve-ce-alienInlineNode\" contenteditable=\"false\"><tt>e</tt></div></b>" Result: "a<b>b<span class=\"ve-ce-leafNode ve-ce-MWEntityNode\" typeof=\"mw:Entity\" contenteditable=\"false\">c</span>d<div class=\"ve-ce-leafNode ve-ce-alienNode ve-ce-alienInlineNode\" contenteditable=\"false\"><tt>e</tt></div></b>" (the difference is in the order of the class and typeof attributes) We should probably implement DOM comparison instead of string comparison in the ce.ContentBranchNode test suite.
Not sure if it is caused by the javasript object keys. May be related to how WebKit/Geck order the element attributes when serialising the html. If the former: ve.getHash or assert.deepEqual If the latter: assert.equalDomElement
This specific case is fixed in https://gerrit.wikimedia.org/r/#/c/57240 by using equalDomElement. However, another case has appeared: recent code introduced full HTML preservation in mw:Image and the attribute order in the HTML serialization matters there too, so now that test passes in Chrome but fails in Firefox (getDataFromDom test 4).
