Description: It's not possible to type text in a "tunneled dialog" in the iOS app. I checked two dialogs: * Edit > Find & Replace... * Tools > Spelling I can switch the focus from one input field to another or change the cursors position in a string, but it seems not possible to enter/type text. Steps to Reproduce: 1. Open a writer document using the iOS app 2. Tap on "Edit > Find & Replace..." 3. Try to enter text in the field "Find:" using an attached hardware keyboard Actual Results: It's not possible to enter text. Expected Results: A user should be able to enter text. Reproducible: Always User Profile Reset: No Additional Info: Tested with 4.2.4 (55) on iPadOS 13.4.1
Confirmed. The virtual keyboard doesn't even pop up. Only affects the iOS app, Online+browser combination is fine.
Aron: Nicolas uses a semi-permanently attached hardware keyboard, I think, so that use case needs to be tested separately. It is different both from using only an on-screen keyboard and using a "normal" (random 3rd-party) Bluetooth keyboard. When using a 3rd-party Bluetooth keyboard, at least the chap "Trust" brand one I have, if you haven't used it for some minutes, it goes into some sleep state and iOS doesn't know any longer that it is there. The isExternalKeyboardAttached() check in the app then returns false, and that (currently) intentionally leads to different code paths being used. Only when you hit some keys on my Bluetooth keyboard the connection gets reinstated and iOS starts receiving that input. But I assume Nicolas's keyboard is different, possibly it is one using the "smart connector" on iPad Pro, so it doesn't need batteries, and the iPad knows that it is there. Anyway, using current online:master and core:cp-6.4, if I make sure my Bluetooth keyboard is not sleeping and is actively connected when I start the app, typing into tunneled dialogs *does* work. It seems that the specific use case that Nicolas is concerned about has been fixed. But let's keep this bug open until we have a fresh TestFlight build out that Nicolas can verify with. That it isn't possible to type into a tunneled dialog using the on-screen keyboard (the keyboard does not even show up, or shows up for a split second and goes away) is a different bug.
And at the moment, testing the 4.2.11 (71) build (from online:co-4-2 + core:cp-6.2), typing into the Find & Replace dialog does not work - Not with on-screen keyboard. When I tap into either text field, the on-screen keyboard pops up but immediately pops down again - Not with the Smart Keyboard Folio. (I now have a such, yay, this is what you Nicolas have, right?) No input from the keyboard is accepted after I tap into either text field - Not with a Bluetooth keyboard. I make sure they keyboard is connected (check by typing into Notes), start the CO app, open a text document, open the Find & Replace, and tap into either text field and type on the keyboard. Nothing shows up. So it seems that this has regressed badly during the month.
@Tor: yes, I have a "Smart Keyboard Folio" (not sure what generation - I bought it June 2018). This is it: https://www.digitec.ch/de/s1/product/apple-smart-keyboard-ch-ipad-pro-105-ipad-air-2019-ipad-2019-tablet-tastatur-6345553 Just FYI: the pupils have a different one - but I'm not sure which one (can figure out if useful).
Sigh. A day of mostly fruitless debugging and staring at more and more debugging output added to the JS and C++ code. Then, I decide to try to see what happens if I use the CollaboraOnlineWebViewKeyboardManager also in the case of hardware keyboards. (Which at first sounds a bit silly, as that code was developed to make the *on-screen* keyboard display and hide more reliably from our JS.) And lo and behold, now I can type with the hardware keyboard into the tunnelled dialog. Odd.
Tor Lillqvist committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/online/commit/c8b1b8623a7bc7d36027001d2c6ce369009dc0f0 tdf#133279: Add another workaround for loleaflet weirdness
Tor Lillqvist committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/online/commit/d0edfeabbdc969a9a66cf90976a63c2f4403a6d3 tdf#133279: Use CollaboraOnlineWebViewKeyboardManager also for hw keyboards
This issue has beend fixed and can be closed in my opinion. Tested in 6.4.0 (5). Thanks a lot to the Collabora team and especially Tor for taking care of this!
Re-opening as I reverted the "Use CollaboraOnlineWebViewKeyboardManager also for hw keyboards" commit.
Should be fixed now with https://github.com/CollaboraOnline/online/pull/596 and https://github.com/CollaboraOnline/online/pull/597 . (Only the co-6-4 branch could actually be verified.)