The trick is that actually the 'onInput' (the 'input') event decides
what data we should actually use - if those from compose event, or from
the text input event.
With this, things finally seem to work reasonably well - I am able to
insert even emoji :-)
Change-Id: I9f19d1e56e4e638cf88b8497abb8eefd24e82cee
Reviewed-on: https://gerrit.libreoffice.org/61337
Reviewed-by: Aron Budea <aron.budea@collabora.com>
Tested-by: Aron Budea <aron.budea@collabora.com>
(cherry picked from commit 10bfc4b449577590c4de82cb15d73204be053a3c)
So that it is possible to press Enter while still in composition.
It is necessary to stop the composing itself, because otherwise the word
gets duplicated on the new line as soon as the user presses a key.
Change-Id: I78951a423715e71533f1a73d5bbe3b0f0f05e6cd
Reviewed-on: https://gerrit.libreoffice.org/61334
Reviewed-by: Aron Budea <aron.budea@collabora.com>
Tested-by: Aron Budea <aron.budea@collabora.com>
(cherry picked from commit f42e0bb4d1c99c1d229a638e59061ef7985d01e8)
When we are autocorrecting a word, we get a deleteContentBackward event;
in that case we have to delete everything we have composed so far.
Change-Id: I36f3d1afcb9b74ac75dee7d64832cc5a3d346045
Reviewed-on: https://gerrit.libreoffice.org/61333
Reviewed-by: Aron Budea <aron.budea@collabora.com>
Tested-by: Aron Budea <aron.budea@collabora.com>
(cherry picked from commit f176bb1e81b5f3769cb56752c7102f93f2eca024)
Most of the text input on Android in Chrome works via the composition;
only the space has to be entered via textInput.
Change-Id: Icd6cea54a962f324215bb6438265e6500f28421d
Reviewed-on: https://gerrit.libreoffice.org/61332
Reviewed-by: Aron Budea <aron.budea@collabora.com>
Tested-by: Aron Budea <aron.budea@collabora.com>
(cherry picked from commit 04b858d90fb1de00f312efcbf131bacda5479e7c)
Makes things simpler and easier to follow, I hope. I had hoped it
would also make the occasional hang I see when loading the document go
away, but nope. Possibly it isn't caused by FakeSocket after all, even
if FakeSocket is the obvious first suspect.
Removes race conditions between kit messages and browser.
Avoid storing old state wherever possible.
Change-Id: I56aa57df22a4190881c8d197df8445ca542d4fc1
max-height it is used for window size, max-device-height
it is the device screen dimensions, so when a tablet
rotate to landscape we keep the mobile layout
Change-Id: I921007014a63374114ec7563144f3532a53fd021
Reviewed-on: https://gerrit.libreoffice.org/61339
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
Tested-by: Jan Holesovsky <kendy@collabora.com>
"permanently" disappears
This forces to blur and focus the text area even it is focused
because there is no way to determine when the soft on-screen keyboard
disappears
Change-Id: Ib89ecc42fb795e34032564a62715463dd944c588
Reviewed-on: https://gerrit.libreoffice.org/61277
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
Tested-by: Jan Holesovsky <kendy@collabora.com>
Sadly we can't use the so-called user-defined LOSRCDIR and LOBUILDDIR
variables from the Build Settings in the pathnames to files. We have
to use relative pathnames, so if attempting to build this you need to
fix them all (instead of just editing the LOSRCDIR and LOBUILDDIR
values), most easily by editing the project.pbxproj manually.
Anyway, for me now I don't see any "red" (not found) referenced files
any more in Xcode.
Use the same discovery.xml and the ClientRequestDispatcher::
InitStaticFileContentCache() call as in Online, even if as such we
aren't serving any "static files" (like discovery.xml) to a WOPI
server in the mobile app case.
To get that with CoreGraphics on iOS we need to use also
kCGImageByteOrder32Little in the CGBitmapContextCreate() call,
otherwise the bytes will be in ARGB order in memory.
Also, yes, we do need to turn the coordinate system upside-down from
the top left corner.
Change-Id: I424afe0184a64b7f069d896bde6941e42b7b5531
rational: setup is easier in case, when user does not use ssl in loolwsd config
Reviewed-on: https://gerrit.libreoffice.org/61076
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Tested-by: Andras Timar <andras.timar@collabora.com>
We try to decrease the network usage with avoiding sending out
to much tiles to the client. When we already sent out two versions
of the same tile without having the tileprocessed message from the
client we delay sending out the next version to avoid spamming tiles
on the network.
Change-Id: Ia47cd7c0d3fb829f6777f0c3265970433591df19
It's good if this limit big enough to send all the tiles of the
current visible area at once, so the tiles arrive at the same
time to the client by zoom or scroll. Now this value is set to a bit
bigger so if we have a small amount of tiles before zoom / scroll we'll
still see the same on the client side.
Change-Id: I8e28dbf6197fe2f683fe9528e9a32c15a191b20e
Some times tiles with the same wireID survives the wireID
filtering in kit, so we should do that in wsd too.
The issue is with the tilesBeingRendered construction. First when
one tile is filtered out on kit side the client remains subcribed
to the tile, since wsd does not know filtering happened.
Second via the tilesBeingRendered object more clients can be subcribed
to the same tile and so when one client request a new version of this
tile (with an old wireID) the rendered tile is sent to all subscribed
clients even if the other clients has up-to-date tiles.
Change-Id: I4ca6b7a83a5d6979a9f924d766a71aba5e5362c7
Since this commit:
9473908d45
We can avoid that, because the tiles will be invalidated
on the client side and when the client visible area changes
the invalidated tiles are requested anyway.
Change-Id: I272e3b4b87380ae574c16a2b480dbc8caabf4b32
I changed the code in this commit:
c2a5f6acb0
To make kit send a tilecombine message even if it does not
send actual tile data so we can track that the rendering was
done and so we can update the clients' _tilesBeingRendered
list. The issue is that tileBeingRendered object
belongs to not only one client, but more and so we don't
know which client gets the actual empty tile response.
So revert this method and rather use a smaller timeout for "waiting" the
arrival of the rendered tile.
Change-Id: I2dbbab1a62b81cbbb5314f2f37fdbc3415c69130
When we're doing the prerendering we also need to register
a tileBeingRendered object, so we know that the given tile
will arrive soon. In earlier version of the code, rendering
and sending of the tile was not separated in time, but now it is,
so we need create a tileBeingRendered object even if we don't
subscribe the client to it yet.
Change-Id: I1374c22e5ffebe1d6fcc6e37261ddcedeb9066ec
This invalidCount does not work perfectly, since we don't always
send tile after every invalidation message (e.g. tile deduplication
on severs side, wireID handling). So this invalidCount usage should
be reconsidered. Now just avoid to have a tile still invalid after
we requested (and get) the newest tile when we are changing the view.
Change-Id: I249be63611767af02b04e142bb1c2afcb3a8eebb
