core.git supports both since commit
4063dcdc7305177b167bd20b009b1dfede8b25ec (Revert naming back to lool to
fix break with LibreOffice Online, 2022-08-26), let's go with the API
name, not with the product name.
Signed-off-by: Miklos Vajna <vmiklos@collabora.com>
Change-Id: I204c4728628579edeb23d5ba76af4bb878130203
We don't want leaking tiles to take up valuable space on the device.
Not even just while a document is open.
Signed-off-by: Tor Lillqvist <tml@collabora.com>
Change-Id: I761c2bb2ab121ee76b5535e96bd5702d0fce6856
Normally (ideally), tiles (.bmp files) are removed as soon as the JS
has displayed them. But occasionally something goes wrong and they are
left behind. (For instance, it seems to happen if the user closes the
document immediately when it shows up.)
Do not leave them on disk until the app starts the next time.
Change-Id: I0c764280a69a16ad3b7b67c329832fd5331c2e1e
Signed-off-by: Tor Lillqvist <tml@collabora.com>
Remove the app's copy of the document after core has saved it and we
have stored the edited version at its real location.
Remove possible leftover tile bitmaps when the app starts.
Signed-off-by: Tor Lillqvist <tml@collabora.com>
Change-Id: Ibc41be38c2cfb689c532640d148116bc06a248ab
Trying to remove such a "file" caused a crash.
Sure, loleaflet should ideally not send such REMOVE messages at all.
No idea why the image for a tunnelled dialog shows up as a data: URL
and not as a file: URL pointing to a BMP file, like the document
tiles.
Signed-off-by: Tor Lillqvist <tml@collabora.com>
Change-Id: I4866ae2c94c626f1947a14353803a9c3d75d5ffa
Unclear whether it is actually useful or not any longer. Quite
possibly cross-platform changes in the JavaScript since
CollaboraOnlineWebViewKeyboardManager was introduced have fixed the
problems that it was solving.
Fixes https://github.com/CollaboraOnline/online/issues/1432
Change-Id: Ifa000d0a7d0a3dc87527536719063b368266f038
Signed-off-by: Tor Lillqvist <tml@collabora.com>
The reverted change caused many problems when using a hardware
keyboard. See https://github.com/CollaboraOnline/online/issues/402 ,
https://github.com/CollaboraOnline/online/issues/389 , and
https://github.com/CollaboraOnline/online/issues/399 .
tdf#133279 (Not possible to type in "tunneled dialogs" on iOS using a
hardware keyboard) will now then re-appear, but it will have to be
fixed in another way.
This reverts commit 68d2d9cbd42f57418927bf3e619e372bb674b218.
Change-Id: Ic723f57a95700f352a2c1f501922aad4eb84479c
Signed-off-by: Tor Lillqvist <tml@collabora.com>
(cherry picked from commit 051e594d7a81d818c16ddce9203bf9b5d929df61)
That way we can use UIFontPickerViewController which gives acess also
to fonst provided and registered by other third-party apps on iOS.
These fonts are not available otherwise. They don't show up when vcl
enumerates fonts in core.
This patch is work in progress for
https://github.com/CollaboraOnline/online/issues/472 . This patch
affects only the font name selection control in the notebookbar. On
iOS this is now no longer a "combo box" (implemented by the external
"select2" Javascript library, if I understand correctly), but a button
that brings up a native iOS control). For now it is just a plain HTML
button. It should ideally later be styled to fit better into the
visual style of the notebookbar.
Change-Id: Ic5e53cad09ffa8c99336dfed594337525909dc90
Signed-off-by: Tor Lillqvist <tml@collabora.com>
(cherry picked from commit 977af5908689425eb55be852a85e56f86070b6bf)
See https://github.com/CollaboraOnline/online/issues/403
Change-Id: I59012565ac6376d03872fe6e4cd78a5d14be1319
Signed-off-by: Tor Lillqvist <tml@collabora.com>
(cherry picked from commit 3a4169a9ebebea56bcdc467691913cd767af878b)
Signed-off-by: Tor Lillqvist <tml@collabora.com>
We don't have any such messages permanently in the code anyway, so we
don't win anything by doing it through the LOOL loggin mechanism at
level "trace".
Change-Id: I2c18e1cd561f797d2c4c20b403d5faedce695062
In theory, this doesn't make sense. In practice, it helps.
Change-Id: I34d03a812c543e1b112851c9e9ff512f2482a20c
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/103714
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
This is a quite complicated change that should both fix tdf#133284
(cursor keys on a hardware keyboard do not work in a spreadsheet
document) and also improve the interaction with
CollaboraOnlineWebViewKeyboardManager that manages the on-screen
keyboard. We need to jump through complicated hoops in order to get
the hardware cursor keys handled right after loading a spreadsheet
document.
In the CollaboraOnlineWebViewKeyboardManager case we try harder to
keep loleaflet's _textArea buffer in sync with what the UITextView in
CollaboraOnlineWebViewKeyboardManager uses to provide suggestions
above the on-screen keyboard.
Also merges in related changes from today to
CollaboraOnlineWebViewKeyboardManager.
Change-Id: Ic4acb54bd4e815aa8bfb2bf40b08493446ae5ab0
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/101878
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
For now, just copy its source files here. When/if I figure out what is
the appropriate way to package that framework for use in other
products (like the Collabora Office iOS app) I will use that instead.
Change-Id: If808f96b6a72c80e54dc84fce80a551503c96335
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/101268
Tested-by: Jenkins
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Avoids the need for PNG encoding (takes significant amount of CPU
time) and Base64 encoding in the app process, transfer to JavaScript
(running in a WebKit process of its own), and corresponding decoding
(in the WebKit process). Instead simply pass the URL of each tile file
to the JavaScript. Remove each BMP file once it has been loaded.
Change-Id: I6e7b9450691679c64813979976c59f1763ec104c
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/98710
Tested-by: Jenkins
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Michael Meeks <michael.meeks@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>
When exporting a copy, let core write the copy to a temp subdirectory
before invoking UIDocumentPickerViewController to select where to
store it permanently.
Change-Id: I3d2292414a3c824515ba6d98ad09b296e543cea9
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/95295
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
We need to catch the downloadas message already in
-[DocumentViewController
userContentController:didReceiveScriptMessage:] and use an
UIDocumentPickerViewController to let the user choose where to
download (or export) the document. The iOS-specific code in
ChildSession::downloadAs() can go away.
Change-Id: I626b9986ec6156f7e83bda02b04e65f7819f8017
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/92112
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
It is enough to call the -[UIDocument
saveToURL:forSaveOperation:completionHandler:] only in
DocumentBroker::sendUnoSave(). And on the other hand, in
-[DocumentViewController bye] we can't want for the
LOOLWSD::lokit_main_mutex as the main queue is needed for parts of
what the saveToURL does.
Also, use a separate copy of the document as the file that is actually
edited by LO core. This matches what the Android app does. I think it
is useful to do this in order to avoid some hangs that I noticed. They
probably were caused by both LO core and the system frameworks
occasionally accessing the same document file at the same time.
Change-Id: Idb65be23a7cb6ad1288fbbd23c7471e0fb8d52f4
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/91851
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
This was added in commit 2174206de1 (android:
Don't hang after returning from a hyperlink., 2020-02-14), but the new command
was only handled on Android. Handle HYPERLINK on iOS, too.
Change-Id: I8c942c1a64c8a52462a749989e312d0d9899a841
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/90917
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
We want to be able to force the on-screen keyboard to be displayed
(when there is no external hardware keyboard) from our JavaScript.
Change-Id: I0678d84ca941a03316ffb68cfd9c3e93a6ea7e57
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/89023
Tested-by: Tor Lillqvist <tml@collabora.com>
Reviewed-by: Tor Lillqvist <tml@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>
Add a "singleton" class method to DocumentViewController to return the
(as for now) singleton DocumentViewController.
Change-Id: I0b8a8def558cfe7f9469b6062a86311dfa63f549
Reviewed-on: https://gerrit.libreoffice.org/82007
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
(cherry picked from commit 2807f907d947549a17c5bae586b85d412d552a09)
Reviewed-on: https://gerrit.libreoffice.org/82021
Otherwise, if you close a document before it has been rendered
completely, the plumbing of threads and FakeSocket connections gets
confused and opening the next document hangs or runs into an assertion
failure. This typically happened for large presentations where
rendering the slide previews takes significant time.
Change-Id: I0f586bec021c4c045a129b3f179ddb3942915c58
Reviewed-on: https://gerrit.libreoffice.org/80882
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
Seems that setting allowsLinkPreview to NO for the WKWebView affects
this functionality, too. Was just an educated guess, and it worked!
Single-line fixes to what initially seems like a hard problem are the
best.
Change-Id: Ic88bf53b883d857338c0316188e079e6797a4d76
Reviewed-on: https://gerrit.libreoffice.org/80208
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
(cherry picked from commit c7e38e6348a98c0a6fcaf20876c57cb01d56f4cc)
Does not fix tdf#125383, though. The WebView still can become zoomed
by manipulating a tunnelled dialog as described in the bug report's
comments.
Change-Id: I9af8d826c58e2065e54b42bc35f74436b0d34a90
It is presumably possible to do it in the JavaScript, too, and then
the same problem would go away for normal Online viewed in Mobile
Safari, too. But I couldn't figure out how. Googling turned up various
advice that suggested using '-webkit-overflow-scrolling: auto;' for
the body of the page but it didn't seem to help. (I tried adding that
to the style attribute of the body element in loleaflet.html.m4.)
Change-Id: Iac3487a73eca218130583dde9decdb89c316c1fc
Spent hours on trying to cleverly use the existing TerminationFlag
(with minor modifications to the code that checks it, and some
additional code to set and reset it), but could not get it to work.
This is simpler, but sure, using a global variable is ugly of course.
At least the new MobileTerminationFlag is very specific in semantics
and only used in the mobile apps.
Change-Id: I0775fdfa7880750ca12c6fd7ec41d3d3ceb2f0ad
The pointer to the DocumentViewController object in the Document class
can be a weak property. This avoids a circular reference.
When the DocumentViewController is being dismissed, remove the script
message handlers and remove the view from its superview. Also, set the
webView property to nil.
I don't have an AirPrint printer so I couldn't verify that it actually
prints, but the system print dialog is displayed and shows a preview
correctly, so I am fairly sure it works.
Change-Id: I5e8a704386cd5053b8689dc63f26e545df323193
It turns out that the view of the DocumentViewController object is
removed from the view hierarchy when the camera is displayed, and
re-added after you choose to use the taken photo. Thus the
viewWillAppear: method is called again at that stage. The Document
object is stil quite intact, though. We should not call the Document
object's openWithCompletionHandler: method again, as that will cause
horrible brokenness.
Change-Id: Ib79bd8f292b01a19866278c4d95a2e816dcd9235
Even if the LO core code, as called by the Online code, already has
saved the document back to the file from which it was loaded, in order
for a file provider extension like NextCloud to notice that, it is
essential to call saveToURL:forSaveOperation:completionHandler:. The
contentsForType:error: method can just return a NSFileWrapper for the
same, already saved, file, though.
Change-Id: Ic063c8603ca38930083866d973e500336cad517e
