Until now, for the "local save has completed, upload it back to the
content: URI" messages we were relying on the "local save" -> JavaScript
-> Java -> "upload to content:/ URI" chain.
It turns out though, that the WebView can be dead by the time we need
the notification that the save has completed. This was particularly
seen on ChromeOS when the document was closed using the [x] in the
window decoration.
As a solution, we need to pass the info that the "local save" has
completed directly to Java. So far this uses the same semantics as the
postMobileMessage() and reuse its code; but maybe in the future we'll
need to split this.
Change-Id: If1b93e4f76cee3abc6aebfc3e9072810ab73bb42
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/98773
Tested-by: Jenkins
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
A small re-factoring to help planned re-plumbing of the iOS app.
Change-Id: I21f09216a7c5adf965179765a75f5a0d521cd7f3
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/97771
Tested-by: Jenkins
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
- read settings from loolwsd.xml
- in case of notebookbar activated send :notebookbar parameter
- for mobile apps I left empty parameter in setupKitEnvironment calls
Change-Id: I5813589564b37eecc1e77c5d0eb737eca5f92f04
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/97233
Tested-by: Jenkins
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
Seems to not cause any serious regressions in the iOS app or in "make
run", but of course I am not able to run a comprehensive check of all
functionality.
Change-Id: I44a0e8d60bdbc0a885db88475961575c5e95ce88
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/93037
Tested-by: Jenkins
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
It was made static in ea2b77ce07 for
Android's sake, so returning it to be per-instance is not a big thing.
Keep a separate static just for the Android app's use for now, while
the Android app supports just one open document at a time anyway. (It
is for the iOS app that I am moving towards supporting multiple open
documents at a time.)
Change-Id: I7fabeb21883eb7cd7155e880eb4cc0413124d1f8
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/92625
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Particularly configuration layers so we can tweak mobile config
easily.
Add core source files from configmgr for breakpointing convenience in
the iOS project. Add loolkitconfig.xcu to the iOS app bundle. Use
${BRAND_BASE_DIR} instead of a compile-time LOOLWSD_CONFIGDIR literal
on iOS (because there is no compile-time constant path to the app
bundle). No "registry" directory directly in the app bundle any longer
on iOS, a corresponding change in core.git moved that stuff to be
under "share", like on other platforms.
Change-Id: I6672efc0505abf27297c4758118a20992b10ceb3
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/88765
Tested-by: Michael Meeks <michael.meeks@collabora.com>
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Effectively both approaches were doing the same thing, let's unify to
the iOS way to minimize the platform-specific code.
Change-Id: I11290410a536c26db054ffcb87e3b64cc2a11c07
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/84589
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
In andorid app, we just supported html or text to be copied between
applications (inside the document the copy/paste is handeled by
the core). The biggest problem with this is that copying between
documents doesn't work or works just as good as our HTML support
is. With this change, we get all the clipboard content after copy
and serialize it to a file into the cache and if we then paste in
another document, we read the content of the file and paste
without any loss of fidelity.
Change-Id: I3501045ff2e815a7e2f8c6ecce5255511c256ca6
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/86833
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Michael Meeks <michael.meeks@collabora.com>
don't do copy/paste in the JS if we can avoid it.
support text & html for cut / copy and share code.
inject our own origin cookie to allow local short-circuiting.
Change-Id: I3187104e9602e86b50cf52d45a9277db44ca8b3b
Reviewed-on: https://gerrit.libreoffice.org/85455
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
First of all, we shouldn't destroy the document in onStop(), instead do
that in onDestroy(). onStop() should only (auto-)save the document, but
otherwise keep it open, so that when we return from the file picker
Activity, the caret is at the same position as it was before.
In addition to that, we should close any open document before we try to
open the new one (in createLOOLWSD).
And finally, when closing the document, we should wait until after the
LOOLWSD is completely torn down, so that we avoid the risk that the user
tries to load another document too quickly, and the messages from the JS
go into the old, still running LOOLWSD.
Change-Id: Ib775021bccc5d5bc69aae392a88dc62a7c05a8fa
Sometimes when closing & reloading a document, the JS ended up with:
cmd=/storage/0/...document_name... type=unknown
error. The problem was that the HULLO response came later than the next
message in the queue which was
loolclient 0.1
So LOOLWSd tried to load the document called "loolclient 0.1", which
failed, and then it did not know what to do with the "/storage/0/..."
which it understood as a command.
Seems we don't need to send the stuff from a thread on Android, so let's
avoid that, instead of setting up another sender queue here.
Change-Id: I96b4ad13153f1cad6aeb7fc71efcb402edbdc6d2
This way, it is more naturally visible what is the actuall app (with the
initial recent documents / file picker) and the editing part.
Change-Id: Ia764f2900939e980f703e3da9f9abd6c0aee7cbb