tdf#109376 sw: fix SwUndoDelete with end pos on SwTableNode crash
Commit 6ff263b8 added a check in SwUndoSaveContent::DelContentIndex() to avoid moving the anchor of a FLY_AT_PARA if its new position would be a table node, because SwFlyAtContentFrame::Modify() requires a SwTextNode to be the anchor. However, that doesn't actually avoid moving the anchor - later, SwNodes::RemoveNode() relocates the anchor to the next node regardless of type! It's probably better to just delete the fly in the situation when the end position is a SwTableNode, which fixes the reported crash. Unfortunately on Redo, the SwUndoDelete::UndoImpl() does not recreate the nodes correctly, hence the fly then is inserted on the wrong node, which later crashes again. The problem is that due to the table node, a dummy SwTextNode is inserted, which should be at the end of the range, but ends up at the start due to an erroneous ++aPos.nNode; - the result is that the fly is inserted on the dummy node and is immediately deleted again, triggering another assert. If there is a dummy node, it also doesn't make sense to call SplitNode(). Yet another problem is that in SwUndoDelete::UndoImpl(), the frames for the moved text nodes are not created, because the first node is skipped with the wrong assumption that it already has frames. Reportedly this started to crash with commit e07feb94, previously it was just wrong. Change-Id: I5094638e34c6ed52c836e57691d377b8cd1608f9 Reviewed-on: https://gerrit.libreoffice.org/70683 Tested-by: Jenkins Reviewed-by:Michael Stahl <Michael.Stahl@cib.de>
Showing
Please
register
or
sign in
to comment