VisualEditor: ce.ContentBranchNode tests fails in Firefox due to object key order
OpenPublic

Description

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.


Version: unspecified
Severity: enhancement

bzimport added a project: Technical-Debt.Via ConduitNov 22 2014, 1:14 AM
bzimport set Reference to bz44808.
Catrope created this task.Via LegacyFeb 9 2013, 1:53 AM
Krinkle added a comment.Via ConduitFeb 22 2013, 9:44 PM

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

Catrope added a comment.Via ConduitApr 4 2013, 12:02 AM

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).

Jdforrester-WMF moved this task to Backlog on the VisualEditor workboard.Via WebNov 24 2014, 6:42 PM

Add Comment