Description: Closing the app in iPad OS 13 (iOS 13) results in a crash. Steps to Reproduce: 1. Open the iOS app in iPad OS 13 (iOS 13) 2. Double tap the home button to see all running apps 3. Swipe away the iOS app (close the app) Actual Results: The app crashes and the crash dialog opens. Expected Results: The app should be terminated correctly. Reproducible: Always User Profile Reset: No Additional Info:
Note that with "closing the app", Nicolas means killing it by force, by double-tapping on the Home button to bring up the app switcher, and then flipping the Collabora Office app off-screen, which kills it. Killing apps like that is as far as I know not something Apple has ever recommended, and all credible expert opinion I have read says that doing it is completely unnecessary, and in fact harmful (because it removes the app's code pages that might be paged in, thus starting the app next time will be slow). The operating system takes care of killing app process when their resources are needed. I certainly hope the Bern school kids are not taught to use iOS like that? I never do it myself, unless some app truly is stuck.
How does this crash dialog look btw? It might be possible that there is pointless code in the app still that tries to catch some signal and log it, code useful in web-based Online server. But in an app there is no need for such.
Hi Tor It seems to be fixed! Let me investigate, but right now, I can't reproduce it anymore.
It's fixed in 4.1.64. I tried with 4.1.63 - and it's reproducible there. I think we don't need to further invest time here and can close this issue. If you d'like I can send you a screenshot of the crash dialog from the older version.
The crash dialog would be useful, yes. Also, as far as I know there were no changes between 4.1.63 and 4.1.64 that would have affected this, but hey, wouldn't be the first time bugs are fixed by accident;)
Created attachment 154852 [details] Printscreen of the "crash dialog" Sorry for not having it in English. Changing the iOS language did change all dialogs but not the language of the crash dialog. It says (freely translated by me): "Collabora Office" has crashed. Do you like to send additional information to the developer?
Created attachment 154854 [details] Printscreen of the "crash dialog" I typed some text into the text field and submitted the feedback - you should probably see it somewhere in the "TestFlight" program?
OK, yep, this is related to TestFlight then.
OK, I installed 4.1.63 from TestFlight and I did see the dialog, yes. And I saw it with 4.1.64 from TestFlight, too. (4.1.64 is available in TestFlight only internally to Collabora people.) With 4.1.64 from the App Store, no such dialog appears. (But instead, I guess, the general permission to share crash logs that you either give or not when taking an iOS device into use applies.) Anyway, I will quickly check whether the core code in LO sets up some signal handler that perhaps get invoked when doing the "force kill". (In case what "force kill" does is to first send some signal that can be caught, like SIGABRT.) That is counter-productive on iOS.
Tor Lillqvist committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/online/commit/39ddc5242d9378566626d9c3a73e9fda91d1129a tdf#126974: When we are about to be killed, just exit bluntly
The above (the same change is in the cp-6.0 branch) should hopefully take care of the problem. Will know when I build the next TestFlight version.
A related but different bug is that if you have a document open, you have done some edits, and then switch to other apps for a while, and those apps require lots of system resources, the system will notify the Collabora Office app that it will be terminated. This invokes the same applicationWillTerminate: method of the UIApplicationDelegate. I.e. it presumably used to cause a crash, and now will just cause it to exit without crashing. What it *should* do is probably cause the current document to be saved in an orderly fashion, and only then exit. That is probably not easy to implement. But I should probably file a separate bug for that, yes.
The issue is not present in the TestFligh version 4.1.65 anymore! Thanks Tor and the Collabora Team for fixing this! I think this issue can finally be closed now.