This is really getting out of hand. I had another document saved as a .doc file and have been working on it for several hours today. This document also had text boxes and a photo. I saved the document one more time and closed it. Then I checked my e-mail where I saw the "resolution" of the last bug I filed, which said I should save any future documents as .odt files. With the intention of doing just that, I reopened the document immediately, and the whole stinking thing was blank! Not one thing was on the page. Every text box was gone, as was the photo. I didn't have a chance to save it as an .odt file! WTF is going on with LibreOffice that things keep disappearing? These two documents represent DAYS of work...gone.
Could you upload the file for examining ? Or if the file contains confidential data maybe you should contact a dev through IRC. And he/she can examine the file for you and maybe fix it ?!
Marking as NEEDINFO until the requested file is provided.
Created attachment 115782 [details] Page with disappearing text boxes and image
Happy to attach it, but I'm sure it won't help - it's a .doc file, as I said, and it's blank. In addition to everything disappearing, it lost the second page (which didn't have anything written on it, but it was there) as well between saving, closing, and opening it again. Additional note: I tried just now to start working on the same document again, as the page was blank, so I thought I'd start over. I added a text box in the upper left hand corner, typed in text, made it bold and centered it, then tried to move the text box slightly. It completely disappeared. The "Edit" function (undo text box move, I think it said) seemed to think the text box was there somewhere, but nothing reappeared. This was without saving and closing the document.
New twist: I downloaded OpenOffice and re-saved the version of the document I'd uploaded to Bugzilla as an .odt file. When I opened it in OpenOffice, all the text reappeared! I added a couple of things then looked at it in Page Preview and - nothing. Blank page. Exported it as a .pdf - blank page. Closed it and re-opened the same .odt document in LibreOffice - blank page. Closed and re-opened again in OpenOffice - all there, except not in Page Preview. Took screen shots out of curiosity, pasted them into a new OpenOffice .odt document - shows up just fine, including in Page Preview and when exported as a .pdf. Opened the .odt screenshot in LibreOffice, and all it showed was two boxes with a note in the upper left corners: "graphics1" and "graphics2." So for the .odt document, LibreOffice shows nothing, OpenOffice shows all text except in Page Preview. Any ideas are welcome, and thanks.
On pc Debian x86-64 with master sources updated today, I could reproduce this. I noticed these 2 logs on console: warn:sot:5471:1:sot/source/sdstor/stgdir.cxx:425: Trying to resize readonly stream by seeking, could be a wrong offset: 7733 warn:sot:5471:1:sot/source/sdstor/stgdir.cxx:425: Trying to resize readonly stream by seeking, could be a wrong offset: 7733
Created attachment 115784 [details] bt from a breakpoint
Michael: sorry to cc you since I suppose you must work on VclPtr related bugs but could you confirm that it's indeed related to tdf#47148 or did I just misunderstand the real problem? (I attached console logs and bt) Bonus question: do you know if something is planned about tdf#47148 (which seems more like a metabug)?
In tdf#47148 the problem was that there are missing images. In this one, everything is gone, including frames and text. I converted the doc to docx with an onlineconverter. Then I could see most of the frames and text again (bit misplaced but...). So it is actually saved, but fails on loading or so.
odd; if this is a regression - I guess it could be some file-format import crasher fix that causes an exception to be thrown on bad data (if it previously worked) which (I conjecture) stops the filter from continuing its work. That's not helpful I guess, but I'd not mark it as an image management shambols, but more of an import issue. HTH.
(In reply to Michael Meeks from comment #10) > odd; if this is a regression - I guess it could be some file-format import > crasher fix that causes an exception to be thrown on bad data (if it > previously worked) which (I conjecture) stops the filter from continuing its > work. Well, I don't think it is a regression. LO 3.3.4 couldn't read it correctly either. Already put the earliest affected version to 'inherited from Ooo' but someone put it back. > That's not helpful I guess, but I'd not mark it as an image management > shambols, but more of an import issue. > HTH. Tried to open the file with wordviewer under win 10 and had no problem opening/reading the file. So yes, it could be an import issue.
Still reproducible with: Version: 5.4.0.0.alpha0+ Build ID: 33f5bc54aaa7fe7aa9335726e30f9c349155e04d CPU Threads: 4; OS Version: Windows 6.2; UI Render: default; TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2016-12-01_23:21:05 Locale: nl-NL (nl_NL); Calc: CL File does show an image with: Versie 4.0.0.3 (Bouw-id: 7545bee9c2a0782548772a21bc84a9dcc583b89)
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Repro Version: 6.2.0.0.alpha0+ Build ID: 7414e07f52af87094240f5c3d9a0eb764e8642f5 CPU threads: 4; OS: Windows 6.3; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2018-06-24_01:44:59 Locale: nl-NL (nl_NL); Calc: CL
Still reproducible with this version: Version: 6.3.0.0.alpha0+ (x64) Build ID: 0f25a3c36f27fd51453b9a9115f236b83c143684 CPU threads: 8; OS: Windows 10.0; UI render: GL; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-11-27_20:06:55 Locale: zh-TW (zh_TW); UI-Language: en-US Calc: threaded
Hi all! The same bug reported by Reported h8j18k24p4s2 at aol.com in 2015-05-20 23:15 UTC happened to me today. I worked hard on a *very important* academic text. After making the last docx save I turned off my Debian Linux 4.19.0-6-amd64 Debian 10 Buster KDE 5.54.0 Plasma 5.14 and decided to have some sleep. Today, I woke up to finish my work and the document now opened only with the first paragraph of a text that already had 5 pages. I re-check several times if that was the correct document, accessing it through most recent files, etc. I will have to do it again with a shortened deadline and with an incredible amount of stress, trying to remember all the hard and complex thoughts I have written before, which is an insane task. This was the final text for my presentation before an academic committee. I will never trust Libre Office again after that.This was a brutal bug and that could have cost me a lot. I will have to take paranoid measures to back up my text before using libre office for important matters again. Unbelievable! Libre Office version: 6.1.5.2 Compilation ID de compilação: 1:6.1.5-3+deb10u5 CPU Threads:4; SO:Linux 4.19; VCL: gtk3_kde5; Local: pt-BR (pt_BR.UTF-8); Calc: group threaded I have no time to follow up now. I'll be too busy trying to save my skin.
Happily, I was able to open the document using Microsoft Office on Windows. This is some kind of document visualization error that occurs after it is saved in MS Word format by Libre Office.
Also in 4.1 but not in LibreOffice 3.5.7.2 Build ID: 3215f89-f603614-ab984f2-7348103-1225a5b
Bibisected with Linux 41max to https://git.libreoffice.org/core/+/83ba821c10392c08334f7d8d3775fe3e8d08f8fd%5E!/ Fix #i120928: Import Graphic Bullets of MS Word Document
Normally we need ODT source from LO or DOC/X from MSO. This is DOC from LO and usually not valid source, nor we can test filesave bug that made it, but since it opens in MSO, we may call it now fileopen bug with low priority.
Dear h8j18k24p4s2, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Repro 7.5+.
In a totally bizarre state, I can open Arcmia Product Page Layout.doc perfectly fine on one of my development builds, but the page is totally empty on another build. It is also still empty in bibisect-linux-7.6.
(In reply to Justin L from comment #23) > In a totally bizarre state, I can open Arcmia Product Page Layout.doc > perfectly fine on one of my development builds That is because when you: -turn on View - Formatting marks, and -tools - options - Writer - Formatting Aids - Display Formatting: Hidden Characters then you can see the hidden content. And since everything is in frames that are anchored to a hidden paragraph, the page is empty.
already marked as hidden in OOo 3.3. It doesn't look like a misplaced hidden marker - it comes from an sprmCFVanish toggling hidden on in direct formatting paragraph properties. <sprm value="0x83c" ispmd="0x3c" fSpec="0x0" sgc="character" spra="0" name="sprmCFVanish" operandSize="1" operand="0x81"/> #0x81 == 129 contrary to style
repro 24.8+ - the hidden attribute still hides all anchored frames/images.