OLE objects corruption bug Description: When inserting an OLE objects inside a document (creating a new one) it gets corrupted. If the file is closed an reopened, the preview stills working, but if you double-click, it is empty, sometimes the preview also is corrupted (mostly for formulas). Insert drawing: always happens. Insert presentation: always happens. Insert sheet: happens once in a while (no pattern detected). Insert text: happens once in a while (no pattern detected). Insert formula: happens sometimes (usually happens when you have been editing for a while, (ex writing three pages of formulas), at the lasts inserted formulas). Technical details: Found in versions: 6.3.0, 6.2.4, 6.2.3, 6.2.1, 6.2.0. Operating system: Debian Stretch (9.9) x86_64, Linux 4.9.0-9-amd64 (may occur on others systems). Source of installation: official deb packages. Reproducing: Create a blank document. Insert a drawing or a presentation (no pattern detected -> no reproducing algorithm). Insert something in it, for example a rectangle (very visible). Save the document. Close the document. Reopen the document. Open the OLE document. Observate.
OLE objects corruption bug Description: When inserting an OLE objects inside a document (creating a new one) it gets corrupted. If the file is closed an reopened, the preview stills working, but if you double-click, it is empty, sometimes the preview also is corrupted (mostly for formulas). Insert drawing: always happens. Insert presentation: always happens. Insert sheet: happens once in a while (no pattern detected). Insert text: happens once in a while (no pattern detected). Insert formula: happens sometimes (usually happens when you have been editing for a while, (ex writing three pages of formulas), at the lasts inserted formulas). Technical details: Found in versions: 6.3.0, 6.2.4, 6.2.3, 6.2.1, 6.2.0. Operating system: Debian Stretch (9.9) x86_64, Linux 4.9.0-9-amd64. Operating system: Windows 10. May occur on others systems. Source of installation: official deb packages. Reproducing: Create a blank document. Insert a drawing or a presentation (no pattern detected -> no reproducing algorithm). Insert something in it, for example a rectangle (very visible). Save the document. Close the document. Reopen the document. Open the OLE document. Observate.
Please be specific. Which LO module, which document? These may be multiple issues (drawing is different from presentation from sheet..). Did you search for existing bugs?
(In reply to Timur from comment #2) > Please be specific. Which LO module, which document? > These may be multiple issues (drawing is different from presentation from > sheet..). Did you search for existing bugs? I searched for similar bugs, but no results (at less with my words). It happens on documents of all kinds and for many of the OLE object types. I listed it as a single bug because it appears to be a data-loss problem of the OLE object handling system (I don't know enough about the Libre Office structure to tell you where is exactly located the bug).
Thank you for reporting the bug. 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
(In reply to Xisco Faulí from comment #4) > Thank you for reporting the bug. 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 I did what you asked me (full reset). I tried with the 6.2.5 and 6.3.0 b2 at the Debian 9.9 computer and with the 6.2.4 at the Windows 10 computer, but persists. The 6.1.6 stills working fine at both.
Please attach sample document and write exact steps for that document.
(In reply to Timur from comment #6) > Please attach sample document and write exact steps for that document. I made a screen-cast showing the problem. https://drive.google.com/file/d/1ACqsrVGBGqRv7siUYDxpqlp7c5cR0vev/view?usp=sharing It happens at all documents (new and old, all modules), but I let here the document I used for the preview. https://drive.google.com/file/d/1kYjiwocJPJFw7ElhuPOunXbrNHb9osUH/view?usp=sharing Instructions: Open the document (with 6.2.0 or later). Open the OLE object. Observate.
The bug stays at the 6.3.0 RC1.
Created attachment 152643 [details] Sample ODT Please attache screencast here, not on Google drive. I attach your ODT. You should have written steps.
Created attachment 152666 [details] Screencast of the bug
The screencast is now attachment 152666 [details]. The instructions to the sample still being: Instructions: Open the document (with 6.2.0 or later). Open the OLE object. Observate. It's just to realize that the rectangle stills not here when you open the OLE object.
The bug stills at the 6.3.0. I've been testing further how it works to get definite patterns and more concrete data. Description: When inserting an OLE objects inside a document it gets corrupted. If the file is closed an reopened, the preview stills working, but if you double-click, it is empty. Summary: Affected versions: 6.2.* and 6.3.*, might still on 6.4 alpha. Tested operating systems: Debian 9.9 (linux 4.9.0), Windows 10, Debian 10 (linux 4.19.37). Instalation: offictial msi installer / offitial deb packages. Data: - It has already been verified that is not an issue related to corruption in the user profile. - The OLE objects witch get corrupted are Impress and Draw modules. - Whatever is the module in witch is inserted the OLE oject, it gets corrupted. - A sample document has already been uploaded (attachment 152643 [details]). - The OLE object is lost when it is opened, but only when it was created before the file was opened (when the OLE object is created everything works fine, if it is closed and reopened it stills working, the problem begins when the file is closed and reopened). - If the document is edited withought opening the OLE object, the data does not corrupt. - If the document is opened with an earlier version (6.1.*) the OLE object works fine, unless if the data has already been lost because the document was saved after opening the OLE object on 6.2.* or 6.3.*. - If the OLE object has been created with an older version (6.1.*) it also gets corrupted. Reproducing instructions with the sample document: 1. Open the document (with 6.2.0 or later). 2. Open the OLE object. 3. Observate. Reproducing instructions: 1. Create a blank document. 2. Insert a drawing or a presentation. 3. Insert something in it, for example a rectangle (very visible). 4. Save the document. 5. Close the document. 6. Reopen the document. 7. Open the OLE object. 8. Observate.
The bug stills at the 6.3.1.
No repro 6.0 and 6.1. Repro LO 6.2 and 6.4+ in Windows, so All. Regression. New.
At 6.2.7 the bug's behavior has changed (see last point). Data: - It has already been verified that is not an issue related to corruption in the user profile. - The OLE objects witch get corrupted are Impress and Draw modules. - Whatever is the module in witch is inserted the OLE oject, it gets corrupted. - A sample document has already been uploaded (attachment 152643 [details]). - The OLE object is lost when it is opened, but only when it was created before the file was opened (when the OLE object is created everything works fine, if it is closed and reopened it stills working, the problem begins when the file is closed and reopened). - If the document is edited without opening the OLE object, the data does not corrupt. - If the document is opened with an earlier version (6.1.*) the OLE object works fine, unless if the data has already been lost because the document was saved after opening the OLE object on 6.2.* or 6.3.*. - If the OLE object has been created with an older version (6.1.*) it works until the file is reopened (after saving). <- Changes
Regression introduced by: https://cgit.freedesktop.org/libreoffice/core/commit/?id=9826a4e4a6aa9953d3f354fe645a23f9dae59d77 author Regina Henschel <rb.henschel@t-online.de> 2018-08-17 19:02:55 +0200 committer Tomaž Vajngerl <quikee@gmail.com> 2018-08-27 16:27:17 +0200 commit 9826a4e4a6aa9953d3f354fe645a23f9dae59d77 (patch) tree 25a38cbe766a092b8df736ab5c75581d77944895 parent 3ed1bd19eb7fb7898bcca8e046e058799f836063 (diff) tdf#101242 Support draw:display and draw:protect attributes of ODF Bisected with: bibisect-linux64-6.2 Adding Cc: to Regina Henschel
The layer status, which is saved, is taken from the active view. But embedded OLE documents have no view. The error was, that in that case the value "false" was written, which means "not visible" and "not printable". The patch in https://gerrit.libreoffice.org/#/c/79701/ changes this to write the default "visible, printable, not locked" in this case. Unfortunately I have yet no idea how to automatically reset the layer status of OLE objects to default on opening the document. To repair the document manually, you need to open it in the patched LibreOffice version, activate OLE, and then save it. Or open it in LO version 5.4, activate OLE, and save it there will work too, because LO 5.4 does not write layer status at all. The error happens on saving. So a repaired document will get the wrong settings again, when saved with a LO version without the patch.
Regina Henschel committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/12f9a9f341fd8f8a98f7cd98f296a8729d279e0d tdf#125585 write default layer status for OLE objects It will be available in 6.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Hi Regina, it seems it's not totally fixed yet. Now in Version: 6.4.0.0.alpha0+ Build ID: d5b7627a0e738c0866b819910153b96b611813f8 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk2; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded I see the blue drawing displayed but it vanishes if I double click on the OLE object...
(In reply to Xisco Faulí from comment #19) > Hi Regina, > it seems it's not totally fixed yet. Now in > > Version: 6.4.0.0.alpha0+ > Build ID: d5b7627a0e738c0866b819910153b96b611813f8 > CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk2; > Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US > Calc: threaded > > I see the blue drawing displayed but it vanishes if I double click on the > OLE object... On comment 17 Regina says it should be solved but didn't know how to uncorrupt the files created with previous versions (6.1, 6.2, 6.3 (version used for the sample)). You will have to create your on sample.
Hi Xisco, to repair the old document, you need to open the OLE for edit and then resave the file. When you then open the document, it should be OK.
(In reply to Regina Henschel from comment #21) > Hi Xisco, to repair the old document, you need to open the OLE for edit and > then resave the file. When you then open the document, it should be OK. Confirmed in Version: 6.4.0.0.alpha0+ Build ID: d5b7627a0e738c0866b819910153b96b611813f8 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded @Regina, thanks for fixing this issue. Backporting to previous branches...
Created attachment 154614 [details] Sample created using LO 6.4.
The LO 6.4 is working fine for the sample document 1 created with an aolder version (attachment 152643 [details]), but it's not working on new documents created with LO 6.4 (attachment 154614 [details]).
@dante19031999@gmail.com: Yes, I can reproduce it with your example. I still have no idea how to automatically repair such documents. For manually repairing, this works for me: Use a version which includes the patch. Go to Tools > Options > LibreOffice > Advanced > Open Expert Configuration. Search for setting 'WriteLayerStateAsConfigItem' and double-click on the search result to set it to 'false'. Then open the faulty document, open OLE for edit, and save document. After having your documents repaired, you can reset the config setting to 'true'. The status of the layer is stored ODF conform in the sub-document styles.xml since LO 6.3. Previously it was only stored in the sub-document settings.xml. The config setting 'WriteLayerStateAsConfigItem' determines, whether the settings.xml is used in addition to the styles.xml or not.
Regina Henschel committed a patch related to this issue. It has been pushed to "libreoffice-6-3": https://git.libreoffice.org/core/commit/a955330e052cc12c622982f38c5f5d138484013a tdf#125585 write default layer status for OLE objects It will be available in 6.3.3. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Regina Henschel committed a patch related to this issue. It has been pushed to "libreoffice-6-2": https://git.libreoffice.org/core/commit/44c0b7416d1abee971ef0b4b17e67f6e391dd807 tdf#125585 write default layer status for OLE objects It will be available in 6.2.9. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Regina Henschel committed a patch related to this issue. It has been pushed to "libreoffice-6-2-8": https://git.libreoffice.org/core/commit/af01bedc4433ed20aa68e98314cc46185a989b1b tdf#125585 write default layer status for OLE objects It will be available in 6.2.8. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Regina, thank you, please mark Fixed.
*** Bug 126434 has been marked as a duplicate of this bug. ***
*** Bug 145877 has been marked as a duplicate of this bug. ***