Bug Hunting Session
Bug 35966 - Change-Tracked Deletion Altered by Writer, Corrupts Rejection
Summary: Change-Tracked Deletion Altered by Writer, Corrupts Rejection
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.3.2 release
Hardware: x86-64 (AMD64) Windows (All)
: medium major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-04-04 13:41 UTC by orcmid
Modified: 2012-02-28 02:41 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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