Description: Opening a presentation twice leads to a crash if the first load was not 100% complete. Steps to Reproduce: 1. Open the attached file and click the "back" button as soon as it's rendered 2. Open the same file again Actual Results: The app crashes Expected Results: The file should open as expected. Reproducible: Always User Profile Reset: No Additional Info: Please see attached video.
Created attachment 149618 [details] Video showing the crash
Created attachment 149619 [details] Presentation which can trigger the problem Not all presentaitons trigger the issue, smaller ones seem to work (not sure if the size is the real problem).
The issue is still more or less present in 4.1.63 (63) and I therefore assume it is not related to #125575. The app doesn't crash as in earlier versions, but the "document is loading" spinner won't stop and the only way to get the app back into a usable state is by killing it. I try to be a bit more precise in explaining what the issue is: * I never tried to reproduce in writer/calc on iOS... * ...but it's reproducible in impress on iOS * One needs a somewhat more complex presentation where loading takes some seconds -> see for example the one I attached to this bug * Open the presentation and wait until the "go back"-icon ("<") is visible * Click the "<" icon while the app is still "preparing" the document * Try to open an other file (doesn't matter which one) This is not a critical bug but some users will run into it when they open larger / more complex files. I sometimes run into it when I realize that I opened the wrong file and then tap "<" to open the correct one while the app is still opening the current file.
Spent most of today debugging and tracing this to little gain.
Just adding some general notes in case I forget, if other more urgent things intervene, and/or if somebody else starts looking into this: Although a good fix for this seems to be hard to find, it is reasonably obvious what the problem is. If one pauses the app process during the never-ending "Connecting..." spinner, one sees that there are two lokit_main threads. That is a clear sign that the plumbing of the separate threads, FakeSockets, and whatnot in the app is totally confused, and no wonder that nothing works. I tried various things including adding mutexes to make sure just one lokit_main() is running at a time, but no cigar so far.
Finally, now I think I have found the right locking to do to keep the lifecycle of the threads and "pipes" (connected FakeSockets) in the app sane also if the user attempts to close a "heavy" document before it has loaded completely. (For instance a large presentation where it takes a long time for the slide previews to be rendered.) Will do some double-checking and then commit.
Tor Lillqvist committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/online/commit/fdb91bf15e04f182311cd263d2492aeb1c3f276f tdf#123733: Keep the WebKit view until the lokit_main thread has finished
Fixed. I testes with 4.1.66 and I can't reproduce the issue anymore. I think this issue can be closed. Thanks a lot to the Collabora team and especially Tor for fixing this issue!