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

Assigned To

Authored By

	Catrope
	Feb 9 2013, 1:53 AM

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

Event Timeline

• bzimport raised the priority of this task from to Low.Nov 22 2014, 1:14 AM

• bzimport added a project: Technical-Debt.

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

Jdforrester-WMF added a project: VisualEditor.Nov 24 2014, 6:27 PM

Jdforrester-WMF moved this task from To Triage to Freezer on the VisualEditor board.Nov 24 2014, 6:42 PM