https://bugzilla.wikimedia.org/show_bug.cgi?id=60117
--- Comment #2 from Roan Kattouw <roan.katt...@gmail.com> ---
I forgot to include how these things lead to the actual failure:
* cloneSliceFromRange returns a slice with an unclosed paragraph opening at the
very beginning, as described above
* The tree build algorithm in ve.dm.Document doesn't actually care about the
unclosed opening and builds the tree as if the mwReference was the first node.
This means we get a mostly valid tree except that all the offsets are off by
one because the paragraph opening element was ignored
* When we try to get the contents of the internalItem associated with the
reference from this unbalanced slice, the range in the tree is one off from the
range in the data array. And so instead of [ {type:'paragraph'}, 'F', 'o', 'o',
{type:'/paragraph'} ] we get [ {type:'internalItem'}, {type:'paragraph'}, 'F',
'o', 'o' ] when calling .getFullData( itemNodeRange, true ) in
ve.dm.MWReferenceNode.static.toDomElements on line 135 (it's actually written
as .getFullData( new ve.Range( itemNodeRange.start, itemNodeRange.end ), true )
which is just WTF and should be simplified)
* This data with two openings and zero closings then gets fed to
getDomSubtreeFromData(), which calls removeInternalNodes(), which spots an
internalItem as the very first element and tries to find its end with
findEndOfNode()
* findEndOfNode() can't find the internalItem closing because there are no
closings, so it tries to throw an error, but that fails because dataElement is
undefined and so accessing dataElement.type is itself an error
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
