Description: I edited a Word docx with track changes and, when I shared this document with the rest of my team, they reported it crashes Word. I have tested and verified this is the case. Steps to Reproduce: 1. Open file in Word 2019 2. Click on line marked with suggested changes/edits 3. Word 2019 becomes unresponsive and never recovers I do not know how to create a document that does this from scratch, but I have a document that does it. Actual Results: Seems to work in Writer, crashes Word. Collaborators upset. Expected Results: Produce a more compliant document? Reproducible: Always User Profile Reset: Yes OpenGL enabled: Yes Additional Info: ersion: 6.4.4.2 Build ID: 6.4.4.2-1.fc32 CPU threads: 16; OS: Linux 5.7; UI render: default; VCL: gtk3; Locale: en-US (en_US.utf8); UI-Language: en-US Calc: threaded
I have a file to reproduce this, but it has some personal information in it that I would prefer not to share publicly. Just let me know if I can send this directly to someone, if that is helpful.
(In reply to PMouse from comment #1) > I have a file to reproduce this, but it has some personal information in it > that I would prefer not to share publicly. Just let me know if I can send > this directly to someone, if that is helpful. Hello PMouse, Could you please send it to me to my email address ? Thanks in advance
Sure thing.
[Automated Action] NeedInfo-To-Unconfirmed
(In reply to Xisco Faulí from comment #2) > Hello PMouse, > Could you please send it to me to my email address ? Thanks in advance Xisco, were you able to reproduce the crash or do you still miss the docment?
Hello PMouse, Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
I can't do that very easily. If it's absolution necessary, I could get to it in a few weeks. But, I can tell you that the symptoms are gone in libreoffice-calc-7.1.4.2-1.fc34.x86_64 . It's fixed, AFAIKT. Does that help? Oh, wait, I marked it resolved on 2021-01-13. Looks like I actually made some notes about it! Looks like I confirmed it was fixed in 7.1alpha, and that was on 2020-06-16. And I marked the issued resolved on 2021-01-13 in Fedora 33. That might not be the exact day, but the fix certainty came to F33 some time before that. FWIW.
Oops, wrong bug!!! Sorry, okay, I'll try to check with upstream ASAP! (In reply to PMouse from comment #7) > I can't do that very easily. If it's absolution necessary, I could get to > it in a few weeks. > > But, I can tell you that the symptoms are gone in > libreoffice-calc-7.1.4.2-1.fc34.x86_64 . It's fixed, AFAIKT. Does that help? > > Oh, wait, I marked it resolved on 2021-01-13. Looks like I actually made > some notes about it! Looks like I confirmed it was fixed in 7.1alpha, and > that was on 2020-06-16. And I marked the issued resolved on 2021-01-13 in > Fedora 33. That might not be the exact day, but the fix certainty came to > F33 some time before that. FWIW.
Dear PMouse, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
Okay, thanks for the reminder. I'll try to get to it this week.
Latest version of LO produces broken .docx files. LO will open the old test file that I shared with you, earlier. I can edit that file and save it again. But, Word 2019 cannot open that file. I tested a new, blank document created by LO and saved as a Word2007 docx forma, and Word2019 was able to open that document and seemed to let me edit it. I also tested a UTF-8 sample .txt format document, which I opend with LO and saved as Word2007 docx format, and Word2019 was also able to open that document. I also re-tested the original test document produced by LO that I shared with you, and Word2019 still hangs immediately after opening it, same as I reported. But, the new test document, which is the old test document that I opened, edited, and saved again as Word2007 docx, cannot even be opened by Word2019. Word2019 gives two error messages. The first error says: "Word found unreadable content in '<document>'. Do you want to recover the contents of this document? If you trust the source of this document, click Yes." If I click "Yes", then I get the next error: "This file cannot be opened by using Microsoft Word. Do you want to search Office.com for a converter that can open the file?" I clicked cancel. I tested the following LO version: Version: 7.2.5.2 / LibreOffice Community Build ID: 499f9727c189e6ef3471021d6132d4c694f357e5 CPU threads: 24; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-US (en_US.utf8); UI: en-US Calc: CL I will attach screenshots of the errors, next.
Created attachment 177473 [details] First Error Message From Word2019
Created attachment 177474 [details] Second Error Message from Word2019
Created attachment 177514 [details] Almost Minimum Working Example Okay, I did a little more testing and found out that this problem is not related to comments or tracked changed, as I originally assumed. It is related to images, somehow. I have a very small working example, now, that exposes the problem. I hope this will be helpful.
This report is unclear. Xisco, did you get the file and reproduce something? PMouse, are you saying that opening LO-created DOCX attachment 177514 [details] crashes Office 2019? I don't have Office 2019 but it doesn't crash Office 2016 and O365. So it looks like NotOurBug.
Validating against "Microsoft Office 2013 Formats" with "Open XML SDK 2.5 Productivity Tool for Microsoft Office" shows 7 error in the attachment "Almost Minimum Working Example". MS Word 365 opens the file without problems, but images cover captions. If I open the file in LO 7.4 and resave it, images and caption are positioned correctly in MS Word 365. Version 6.4 had "End of Life" November 2020. Because current versions of LibreOffice and Microsoft Office have no problems, I suggest to close this issue.
Yes, Timur, that is exactly right. LO v6.4-v7.2.5.2 produces documents, like this, that crashes Word 2019. I don't know anything about other Word versions or 365, but this was a huge problem for me for a while because everyone I work with had and still has Word2019. But, isn't current version 7.2? That's the version I'm reporting against, not 6.4. Also, Word2019 was only just replaced and is supported for almost two more years. I mean, it sounds like 7.4 doesn't have this bug, but that's not even a workaround until it gets released.
Created attachment 177543 [details] Working Example saved in MSO 2016 Closest to NotOurBug because crashing MSO is MSO bug. Especially if it crashes Word 2019 and not Word 2016. Creating wrong DOCX would be LO bug but for that, needed is source ODT which, when saved, creates wrong DOCX. But for test, here is Working Example saved in MSO 2016. Please test if that one crashes MSO 2019. Open XML SDK is rather old tool and I guess there should be better ones. But it shows 4 errors for this file, meaning that MSO saving fixed 3 errors (.
Very interesting. Working Example saved in MSO 2016 produced the same first error: "Word found unreadable content in '<document>'. Do you want to recover the contents of this document?..." However, if I click "yes", the document is shown, a little messed up, but functional. Whereas, the same document exported by LO 7.2.5.2 cannot be converted, apparently, and MSO2019 suggests using the software marketplace to find software to help, but never successfully opens the document. I also tried converting the MWE I provided to ODT with LO, closing it, reopening it, and saving it as .docx. That docx version produced the same two errors as the MWE, which was never saved as ODT. But, the .odt document, in between, produced the same result in MSO2019 as the MSO2016 document you posted. Meaning, MSO2019 generates the error: "unreadable content" when opening the .odt version, but *is* successfully able to "recover" a usable document. I'm loosing track of where all this evidence leads. There is clearly a disagreement between LO v6.4-v7.2 and MSO2019 about the correct .docx format re: images or maybe floats, still not sure what is the core issue. In LO7.2, this disagreement doesn't result in a crash of MSO2019, which is an improvement, but it is still not interoperable.
I think I'll just close this bug. It has wandered around and hasn't been commented on for half a year. It indicates that the latest versions of LO don't contain the problem, and it only affects the latest, supported Microsoft product (which they ought to fix). So this could be WORKSFORME, or NOTOURBUG, but I'll mark as INVALID since it never really pin-pointed any specific problem.