Bug 134694 - LibO changes the text on saving with potential data loss.
Summary: LibO changes the text on saving with potential data loss.
Status: RESOLVED INVALID
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.4.4.2 release
Hardware: All Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-07-09 16:20 UTC by Callegar
Modified: 2020-09-26 00:03 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Text on screen before CTRL-s (204.33 KB, image/png)
2020-07-09 16:21 UTC, Callegar
Details
Text on screen after CTRL-s (223.63 KB, image/png)
2020-07-09 16:22 UTC, Callegar
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Callegar 2020-07-09 16:20:52 UTC
Description:
Working with Libreoffice 7.0 writer, I have noticed that LibO messes the text that is being written.

The most evident case is having a piece of text on screen, pressing CTRL-s to save it and having libreoffice change the displayed text. The two attached screenshots show an example.

Another frequent situation is having some text on screen, selecting it, copying it elsewhere and seeing a different text being copied.

In all cases, the "different" text involves some previous version of the document that has been edited.

It is unclear to me what triggers this very serious issues that causes data loss. My suspicion goes to the change tracking code which I believe was changed in the transition from LibO 6.4 to LibO 7. For sure I had the issue working on one document that was started with LibO 6.4 and the change tracking active and then edited again on LibO 7 disabling the change tracking.

While I will certainly look better in the issue and try to distill a reproducible case, I would like to provide immediate attention to this very serious matter.

Steps to Reproduce:
See description, working on a reproducible case.

So far, I have this:

- open a document with LibO 6.4, write some text into it, save. Activate change tracking. Modify the text, save again. Reopen with LibO 7.0.0 RC1, disable change tracking. Save. Modify the text cutting and pasting from other applications. Save. Select text, copy it into the clipboard and check the clipboard content.

Actual Results:
Saving the document causes the document content to change on screen.
Cutting a piece of text fills the clipboard with a different text.

Expected Results:
LibO should never change the document when asked to save it and should copy in the clipboard the actual text that is being displayed.


Reproducible: Sometimes


User Profile Reset: No



Additional Info:
[Information automatically included from LibreOffice]
Locale: en-US
Module: TextDocument
[Information guessed from browser]
OS: Linux (All)
OS is 64bit: yes
Comment 1 Callegar 2020-07-09 16:21:46 UTC
Created attachment 162854 [details]
Text on screen before CTRL-s
Comment 2 Callegar 2020-07-09 16:22:14 UTC
Created attachment 162855 [details]
Text on screen after CTRL-s
Comment 3 Xisco Faulí 2020-07-09 18:57:55 UTC
Thank you for reporting the bug. Please attach a sample document, as this makes it easier for us to verify the bug. 
I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided.
(Please note that the attachment will be public, remove any sensitive information before attaching it. 
See https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F for help on how to do so.)
Comment 4 Callegar 2020-07-09 20:02:36 UTC
After a few tests, I confirm that the bug appears to be triggered by change tracking and is not a regression (namely it is not unique to LibO 7.0.0 RC 1).

I do not have a test document, but I have a procedure by which the issue is 100% reproducible on my system.

1) Start libreoffice7.0 --writer

2) Open the web page https://lipsum.com/ in a browser to have some text to paste into LibO

3) Check that Edit->Track Change->Record is disabled and copy the first text block of the web page ("Lorem Ipsum is simply dummy text ... like Aldus PageMaker including versions of Lorem Ipsum.") into the so far empty writer document.

4) Activate Edit->Track Change->Record.

5) Copy in the clipboard the second text block of the web page ("Contrary to popular belief ... the 1914 translation by H. Rackham"). Go back to LibO, select the second paragraph paragraph "It has survived not only five ... like Aldus PageMaker including versions of Lorem Ipsum.", paste from the clipboard so replacing this paragraph with the text previously copied from the web page.

5) Disable Edit->Track Change->Record and Edit->Track Change->Show.

6) Copy in the clipboard the third text block of the web page ("It is a long established fact ... sometimes on purpose (injected humour and the like)"). Go back to LibO, select the text "This book is a treatise on the ... 1.10.32", and paste from the clipboard so replacing this text with the text previously copied from the web page.

7) Observe that something weird has happened. Some text well before the one on which the action at point 6) was practiced has changed, causing words that had previously been erased to reappear.

8) Press CTRL-s, see the file selection dialog appearing. Provide a filename and save. See the text changing again.
Comment 5 Dieter 2020-07-24 10:49:32 UTC
I've followed your steps, but couldn't reproduce with

Version: 7.0.0.0.beta2 (x64)
Build ID: 1c213561a365b5666167321de68c9977500c9612
CPU threads: 4; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: en-GB
Calc: CL

To be certain the reported issue is not related to corruption in the user profile, could you please reset your Libreoffice profile (https://wiki.documentfoundation.org/UserProfile) and re-test?

I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the issue is still present.
Comment 6 BogdanB 2020-08-09 19:53:48 UTC
Sergio, please go to Help - Restart in Safe Mode - Factory Reset
Comment 7 BogdanB 2020-08-09 19:54:32 UTC
After that tried to retest your bug, and if it yet reproductibile please comment hear.
Comment 8 Callegar 2020-09-26 00:03:08 UTC
I confirm that I cannot reproduce either from my own steps.

Either I have written them down wrongly, so that they do not actually make a real reproduction procedure, or something has changed on my system (moving to LibO 7.0.2.1?, changed profile?)

Closing for now. I'll reopen if I encounter a similar issue again (hope not).