Download it now!
Bug 89732 - FILESAVE with Tracked Changes modifies numbering to Other than What User Did and Saw
Summary: FILESAVE with Tracked Changes modifies numbering to Other than What User Did ...
Status: RESOLVED DUPLICATE of bug 119571
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
Inherited From OOo
Hardware: All All
: medium major
Assignee: Not Assigned
Depends on:
Blocks: Track-Changes
  Show dependency treegraph
Reported: 2015-02-27 22:34 UTC by orcmid
Modified: 2019-05-15 07:58 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:

This Zip file contains all of the information for confirmation of the defect (267.43 KB, application/x-zip-compressed)
2015-02-27 22:34 UTC, orcmid

Note You need to log in before you can comment on or make changes to this bug.
Description orcmid 2015-02-27 22:34:09 UTC
Created attachment 113768 [details]
This Zip file contains all of the information for confirmation of the defect

This is a Works-for-Me-Not defect.  The tracked change shown to the
    user is not how the tracked-change is saved in the resulting file,
    losing the change as it was observed when it was made.

    The defect in this report is confirmed in Libreoffice and has
    appeared at least as far back as 2.4.3.

    NOTE: The Apache OpenOffice counterpart of this defect is reported
          as AOO Bugzilla issue 126139.
          This defect may also be related to i86812 here. 

The attached Zip file contains the following supporting materials:

d141001-x0001.txt is this manifest and defect demonstration

    This is the initial file of simple nested lists.  The file was
    created using entered text and the standard toolbar buttons to
    make indented numbered lists with outline 1,(a),i nesting.

    This is a screen capture of the file -start.odt as it appears
    using LibreOffice en_US x86 on Windows 8.1 Pro x64.
    Change Tracking is turned on and being shown.

    Screen capture of a selection of text from the end of item
    2. BBBBBB into the beginning of item (a) CCCCCC.

    Screen capture of the presentation after the DEL key is used.
    The list is as created, with the deleted CCC and BB positions
    shown with strike-through and a different color of text.

    This is the file obtained when a Save As ... is performed
    after the change-tracked deletion shown in the -delete.png

    Screen capture of the the -deleted.odt file re-opened in
    LibreOffice.  The deletion is now shown quite differently
    compared to what was presented to the user at the time the
    deletion was made.  This change is also shown immediately
    after the Save As ... is made, although that would not
    be noticed if the change-tracked deletion was not visible
    in the application window at the time.

    This illustrates the consequences of rejecting the altered
    tracked-change.  Rejection does not restore the text as
    it was before the deletion operation was performed.

NOTE: The defect
Comment 1 Buovjaga 2015-03-04 14:49:46 UTC
Reproduced with RCT-2014-09-10-1519-CrossCut-LibO-start.odt and going through the steps.

Win 7 Pro 64-bit, LibO Version:
Build ID: 45e2de17089c24a1fa810c8f975a7171ba4cd432
Locale: fi_FI

Ubuntu 14.10 64-bit
Build ID: 40m0(Build:2)
Locale: en_US
Comment 2 tommy27 2016-04-16 07:28:15 UTC Comment hidden (obsolete)
Comment 3 QA Administrators 2017-05-22 13:26:02 UTC Comment hidden (obsolete)
Comment 4 orcmid 2017-05-24 00:23:42 UTC
The Zip and the instructions were followed using LibreOffice_5.3.3_Win_x64.msi

The test was performed on a Dell XPS 8500 running Microsoft Windows 10 Pro Version 1607.

The test exhibits the exact same defect described in the Zip file.

This defect is also presented as the star example, in section 4.7, Example: Works-For-Me-Not, in the published paper, "Tracked Changes: Navigating the Document-Format Anti-Pattern" that can be freely downloaded via the page at <>.
Comment 5 Timur 2017-07-11 11:41:36 UTC
Still the issue with 6.0+. Updated the title to include "numbering". 
This happens with customized numbering only like here where used with default style. Doesn't happen with heading styles customized with same numbering. 
Dennis, can you please upload other example you mentioned.
Comment 6 Dennis E. Hamilton 2017-07-11 14:22:56 UTC
(In reply to Timur from comment #5)

> Dennis, can you please upload other example you mentioned.

The files I uploaded are the same as the example that is in the publication.
(Sorry, had to create a new account for some reason.)
Comment 7 QA Administrators 2018-07-12 02:44:31 UTC Comment hidden (obsolete)
Comment 8 orcmid 2018-07-22 17:29:54 UTC
Using Version: (x64)
Build ID: 54c8cbb85f300ac59db32fe8a675ff7683cd5a16
CPU threads: 8; OS: Windows 10.0; UI render: GL; 
Locale: en-US (en_US); Calc: CL

There is no change.  The defect appears as described in the original report.

The insertion of list-item 3 (so the last is item 4) and the loss of sub-item heading (a) happens as soon as the document is saved -- the change shows in the still-open displayed document.  Reloading is as modified by save.

Side Comment: I do notice that the Attachment 113768 [details] does not appear to download properly using the Microsoft Edge browser on the latest Windows 10 update.  The filename is some kind of mess.  This might not be a defect though.
Comment 9 László Németh 2019-05-15 07:58:46 UTC
Fixed in Bug 119571. Now deletion shows immediately the correct format of the joined paragraphs, no need to save the file or change to Hide Changes mode for it.

*** This bug has been marked as a duplicate of bug 119571 ***