In the LibreOffice application, when I open a pre-existing docx file that is password protected, and I click cancel when prompted for the password, LibreOffice still opens the document, but all the content is garbled. We are using unoconv with headless LibreOffice for automating converting documents to html. Up until now, we have used LibreOffice v 4.1 together with unoconv 0.6. With this version, attempting to convert the document fails with the message: The document [document name] could not be opened. But we have just upgraded to LibreOffice 4.3, and now LibreOffice "successfully" converts the document, though the output is unreadable. This creates a problem with our automation, because this result is reported back to our users, rather than giving them a more useful error message that the document couldn't be converted. And I think for your LibreOffice application users, the user experience is much worse when they are presented with the garbled document.
setting 4.3 as first affected version and marking as regression.
please upload a dummy test file so we can try to reproduce. is the bug specific to .docx format or happens with .doc and .odt as well? I set status to NEEDINFO revert it to UNCONFIRMED once you upload that file
Created attachment 113466 [details] A password protected .docx file for debugging and testing. Attached a password protected docx file. (the password is 'Secret') To make it password protected, we did the following (this was on Office for Mac): Word menu -> Preferences -> Security tab In there, Security options for [name of document]: Password to open: (filled in password) Clicked on "Protect document" I have not tried with a regular doc file. Also, a password protected .odt file did not have the same behaviour. It worked as before.
The below appears to be the commit at which we started to write a (junk) html file for a password protected .doc instead of nothing when converting with "soffice --convert-to" Adding Cc: to mstahl@redhat.com; Could you possibly take a look at this? Thanks commit e62339f856efa0b8ef03df3bf8b93e098c4ac0d3 Author: Michael Stahl <mstahl@redhat.com> Date: Mon Feb 10 16:45:27 2014 +0100 fdo#73363: sd: fix mis-detection of Visio files as PPT SdFilterDetect::detect() erroneously detects all binary MSO files, and because the Visio types would be checked after PPT, Visio is pre-empted. Change-Id: I6ec3647a508dc8d79b47bfff6de35ccae39416ee
*** Bug 93280 has been marked as a duplicate of this bug. ***
(In reply to Matthew Francis from comment #4) > The below appears to be the commit at which we started to write a (junk) There is, of course, nothing wrong in this commit. What we should do here is to honor the MediaDescriptor::PROP_ABORTED that written by the oox detector, and stop the detection loop (and then also make sure that GUI users won't see the filter selection dialog).
Actually there is much earlier report. *** This bug has been marked as a duplicate of bug 80999 ***
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]