VisualEditor: ce.ContentBranchNode tests fails in Firefox due to object key order
Closed, ResolvedPublic1 Story Points

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

Details

Reference
bz44808
bzimport set Reference to bz44808.
Catrope created this task.Feb 9 2013, 1:53 AM

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

Esanders closed this task as "Resolved".Sep 24 2015, 4:19 PM
Esanders claimed this task.
Esanders added a subscriber: Esanders.

Related: https://gerrit.wikimedia.org/r/#/c/240722/ in MW, where we need to decode data-mw and parse body.html, sometimes recursively :/

Add Comment