[loviewer] If a document is corrupt, docviewer should try to repair it, as LibreOffice does on dekstop

Thank you for testing the 'beta' version of DocViewer and taking the time to report this bug.

Currently we had mixed results when opening .odt files. This is a known bug and it's already under investigation.

Since the bug is not reproducible with all the ODT documents, at the moment I can only mark this bug as 'incomplete'.

You can help us by providing more test cases on which we can investigate.

Please have a look at https://lists.launchpad.net/ubuntu-phone/msg16701.html
If you want, you can get in touch with our product manager (or simply upload the document you've tested here on Launchpad) and provide the informations specified in the mail above.

I'm sorry for this, but we need such informations in order to find out which component is the reason of the crashes.

Thanks for understanding.

I've been testing docviewer with some odt files and I have two apparently identical files which one of them is opened by docviewer and the other one isn't.

Maybe the cause could be that one of them was converted from docx file to odt via Libreoffice and the other has been created directly with Libreoffice.

I attach both.

Thank you for your work.

Thanks for the documents!
However, I had a quick test and I am able to open both the documents on the BQ E5.

The situation looks a bit strange to me, and I think it may be caused by several reasons.
Which device are you using (Meizu, Nexus, BQ)? Could you please do a soft-reset (i.e. reboot your device) and test those documents again, ensuring that no other app than DocViewer is launched?

Anyway this may require some time to be triaged, since the currently ""beta"" release has no error handling on initialization. I'm working on it, so that in the following tests we will be able to get more precise informations from the app itself.

I have more information that could be useful.

When I download the files above (in launchpad) with wget from the terminal (in bq E4.5) both open correctly.

I have those files in a dropbox folder and I've done the following tests:
   - When I copy those files from desktop via adb they open correctly.
   - When I download that files with wget from the terminal with the shared link to each one in dropbox both open correctly.
   - When I download them with uDropCabin (https://uappexplorer.com/app/com.ubuntu.developer.bobo1993324.udropcabin) the file named Test_opened.odt opens well but the file named Test_not_opened.odt makes docviewer to crash.

So, I think it is a bug for uDropCabin.

Thanks for all!

I've copied them to the bq E4.5 with wifitransfer (https://uappexplorer.com/app/wifitransfer.sil) and it both work perfectly.

Then I very sure that the bug for uDropCabin. You can close this bug if you think it.

Thank you!

Even if I copy the downloaded files with udropcabin to desktop via cable, that named Test_opened.odt is opened with Libreoffice and that named Test_not_opened.odt isn't.

So I think udropcabin corrupts some odt files.

Thanks for the detailed informations.
It sounds like an issue I've had when trying to close an .odt document created by Google Drive.

Anyway it would be nice to track any similar issue and see how much often this issue happens and if there's something we can do for recovering from such situations.

I'll keep this bug opened, until we don't decide otherwise or plan something for handling such exceptions.

Thanks again for spending some time on this!

I think you can do nothing because the issue is that some files downloaded by udropcabin are corrupted. Libreoffice in desktop can't open that files neither.

I've filed a bug in for udropcabin: https://github.com/bobo1993324/UDropCabin/issues/17

Thanks for your work, again!

Sure, there's probably not much to do here. Anyway, the first strategy we could implement is to inform the user that his/her document may be corrupt (which is something that DocViewer currently don't do).

Also, we haven't worked yet on a mechanism for recovering from such exceptions (see bug #1514458).
We're currently working on it and, as long as we don't merge a fix for it, DocViewer will just crash with no output (which, as we've seen, it makes users rightly say DocViewer is not working - we didn't allow them to know what's happening).

Today we'll have our weekly meeting. We'll discuss about some solution/workaround.

It has been really a pleasure to get such a big help in finding out the source of the corrupt file.
I'm going to subscribe your report on Github, in order to follow any future discussion.

Thanks a lot!

In case you need it I attach the file which is not opened.

Thanks to all you for doing this amazing app!

I've tried the document with my development branch that fixes the bug #1514458.
The application don't crash anymore, and properly shows a Dialog which informs the user that the document has not been loaded.

That said, there's still room for improvements.
Our discussion pointed out that we need to provide a more detailed description of the error, explaining that the document may be corrupt or damaged.

As we will be ready to release a new testing version of DocViewer (which will include all these changes) we will check for the occurrence rate of this error, and will see if we can do something.

For example, LibreOffice (on desktop) can try to repair a corrupt document. I've tried with the file you've attached at comment #11 and it did the trick.

Thanks again.

I'll be glad to test the next new beta version.

Thanks for your interest.