Bug 35966

Summary:	Change-Tracked Deletion Altered by Writer, Corrupts Rejection
Product:	LibreOffice	Reporter:	orcmid <dennis.hamilton>
Component:	Writer	Assignee:	Not Assigned <libreoffice-bugs>
Status:	RESOLVED WORKSFORME
Severity:	major	CC:	cno, dennis.hamilton, lemoyne.castle, sasha.libreoffice
Priority:	medium
Version:	3.3.2 release
Hardware:	x86-64 (AMD64)
OS:	Windows (All)
See Also:	https://bugs.freedesktop.org/show_bug.cgi?id=37584
Whiteboard:
Crash report or crash signature:		Regression By:

Description orcmid 2011-04-04 13:41:25 UTC

LOffice 3.3.2 Tracked Changes (Load/Save set to ODF 1.2) damages some tracked deletions after the document is saved, leading to incorrect change-tracking if there is further editing/authoring and saving.

The case arises when there are additional end tags added past the deletion point in order to balance the elements that are truncated (ending chopped off) before the deletion point.  The deletion tracking and the in-text markup are initially correct.  

However, the showing of changes in the presentation is subsequently altered.  The alteration fails to properly show the original text in context and the <text:deletion> element is altered.  It appears that the problem arises in the consumer not properly recognizing that some end-tags beyond the deletion seam are synthetic and were not part of the pre-deletion document.

This came up in a forensic analysis of tracked-change deletions on the ODF TC and there is a blow-by-blow analysis on the ODF TC site.  The demonstration document and a PDF of it are available to the public.  See 

http://lists.oasis-open.org/archives/office/201104/msg00008.html

http://lists.oasis-open.org/archives/office/201104/msg00009.html

Although this involves a moderately-intricate deletion case, it is easy to stumble on.  The severity is because after the corruption, the change will be shown incorrectly and, more to the point, any rejection of the change will fail to restore the undeleted text correctly.

Comment 1 orcmid 2011-04-04 14:35:18 UTC

I should point out that this can be more serious if the saved document is saved, the signature is confirmed, but the OpenDocument Consumer presents the change-tracked deletion incorrectly.

Comment 2 orcmid 2011-04-07 10:05:37 UTC

(In reply to comment #1)
> I should point out that this can be more serious if the saved document is
> saved, the signature is confirmed, but the OpenDocument Consumer presents the
> change-tracked deletion incorrectly.

I should have said, "if the saved document is signed, the signature is confirmed, but the OpenDocument Consumer presents the change-tracked deletion incorrectly."

Comment 3 orcmid 2011-06-12 12:48:06 UTC

This bug is similar to the one in LibO 3.4.0rc2 where deleted text is turned into deleted spaces.  That one is worse.

The two bugs seem to be related in the sense that the deletion is recognized correctly, but as soon as anything happens, the deletion is replaced by the incorrect one.

Comment 4 Björn Michaelsen 2011-12-23 11:47:03 UTC

[This is an automated message.]
This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it
started right out as NEW without ever being explicitly confirmed. The bug is
changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back
to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases.
Details on how to test the 3.5.0 beta1 can be found at:
http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1

more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html

Comment 5 sasha.libreoffice 2012-02-27 05:50:53 UTC

Please, verify: in 3.5.0 problem still exist?

Comment 6 orcmid 2012-02-27 17:51:46 UTC

I redid the deletion example that crossed between a list and a paragraph following the last list element, and the change-tracking was visibly correct after saving and reloading the document in LibO 3.5.0 on Windows Vista (32-bit).

When I rejected the change, the original text was properly restored.

Based on that test, the defect does not appear in 3.5.0.

Comment 7 sasha.libreoffice 2012-02-28 02:41:24 UTC

Thanks for additional testing