Store the tile cache names and drop outdated tiles
times to times, so we can avoid tile rendering / sending to
stuck.
Change-Id: Ibff001307c7c660cbc57ab20c29c430e0090444d
I used number 25 as this limit. It's an approximate value. It's enough
to handle the first 5-10 character input without waiting for tileprocessed
messages. After the first 5-10 characters the tileprocessed messages are
arriving continuously (same frequency as the typing speed), so for the later
character inputs we always have some tileprocessed messages arrived so
we can push new tiles to the network again.
This 25 upper limit also seems enough to send all tiles when a whole page is
requested (e.g. zoom os scroll).
We store the requested tiles in a list, used as a queue. I don't use std::queue
because sometimes we need to do deduplication (replace older versions of the
same tile with a newer version).
Change-Id: I22ff3e35c8ded6001c7fc160abdc1f1b12ce3bae
We always one bunch of tiles (e.g. all tiles invalidated) and we
are waiting until client send tileprocessed message back for all
tiles before sending the new tiles.
By canceltiles message we drop every previously requested tiles and
make wsd ready to send new tiles, which will be requested by the client
in theory.
Change-Id: I9901420ada549e962ffaf5e6bd58e52b86bd129d
When asked to "convert" a document to a PNG image, i.e. what one can
call a thumbnail, check if we have a cached PNG for the same docuemnt
already, and in that case return it.
When we have done such a convert-to operation to PNG, save the result
in the cache for later re-use.
This change adds no thumbnail cache cleanup mechanism. That will have
to be implemented separately using a cron job or whatever.
There are further improvement possibilities: For instance, if the
document is of a type that contains an embedded thumbnail (like ODF),
just extract and return that. For ODF that embedded thumbnail even
already is in PNG format.
Change-Id: I882efe97acc1d81041dc7a4ccb222995940e4836
Reviewed-on: https://gerrit.libreoffice.org/57345
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
Log all error: cases in ClientSession::handleKitToClientMessage(), not
just the case of cmd=load with kind= some password failure.
Change-Id: I53c959068f5642ae41157e8feb14fd34fc59dc9a
Since changing the tracking state is done by toggling,
we need to wait to get the current state at load time
before we can tell whether we need to toggle it or not.
Change-Id: Ib5a2639b2acf3874c191971eedf9a3bebcefebad
Reviewed-on: https://gerrit.libreoffice.org/53415
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
Tested-by: Jan Holesovsky <kendy@collabora.com>
Otherwise saving is bound to fail, causing other
errors, which is nonsensical since there is nothing
to save to begin with.
Change-Id: Icb65a4a3b277b3175aadbe5107b294b24a399e7b
Reviewed-on: https://gerrit.libreoffice.org/50148
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Asking the doc broker to close means that it will save the current
document to storage before shutting down. But we don't want that because
storing the current document to storage means overwriting the document
which has been changed underneath us.
Change-Id: I8df45d2f0cf3f65936dc3030f483e52fd1703146
Reviewed-on: https://gerrit.libreoffice.org/49134
Reviewed-by: pranavk <pranavk@collabora.co.uk>
Tested-by: pranavk <pranavk@collabora.co.uk>
Now always given a proper reason too.
Also, stop polling thread and cleanup when
failing to acquire/spawn a child process.
Change-Id: I7ddee01dd47b8ee72f2d9134c0f1b264634d8611
Reviewed-on: https://gerrit.libreoffice.org/47886
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Michael Meeks <michael.meeks@collabora.com>
Maintaining a flag is problematic, at least the way
it was reset on adding new sessions. Luckily there
should be no reason for having it, since we should
check it only when removing sessions. Also, we
need to check for every case of removal, and not, as
was, just on disconnection, which is incomplete.
Change-Id: I878766701228c41fc93eeaff21852fa887de9eff
Reviewed-on: https://gerrit.libreoffice.org/47883
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Michael Meeks <michael.meeks@collabora.com>
use a specific message from the client for set the visibility state of
a group instead of hijacking the update row/column header message
Change-Id: I69d66b30db0b4d8a0082cbd2524120491d4f97cb
Reviewed-on: https://gerrit.libreoffice.org/45446
Reviewed-by: Marco Cecchetti <mrcekets@gmail.com>
Tested-by: Marco Cecchetti <mrcekets@gmail.com>
When saving while editing a cell, the
document is saved with the new cell contents
(as the cell editing is interrupted and applied),
but the modified status is not published to the
client (loleaflet).
This has the unfortunate side-effect that the
EverModified flag is not set in this scenario.
To avoid this, this patch sets the EverModified
upon successful saving. This is easier than
forcing LO Core to emit ModifiedStatus=true
in the scenario above. Though it suffers from
the false-positive result when the user forces
a save. Although this is probably defensible,
since technically the document changes upon
saving (though not the content if there was
nothing new to save). On the other hand,
it's less harmful to signal modification
due to save than to ignore genuine
modification to the document.
Change-Id: I7ccba62731f534b69819f7924eeb9231d874c111
Reviewed-on: https://gerrit.libreoffice.org/38398
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
This is required to tell the clients if the command they issued was
successfull or not. In this case 'savetostorage' is the command that we
are interested in knowing the success status of.
With this, now if the user commands to overwrite the document, dialog
boxes of all other users are automatically closed.
Can easily more commands in future for this kind of thing. Its similar
to unocommandresult, except its not a uno command, but our internal
command.
Change-Id: I2e7e1fd5edbd55c13ee4bf9bce24284483d6507f
There is one known problem still - after any user decides to overwrite
the file to storage, other users are not informed, so their dialog keeps
hanging on the screen until they press the cancel or reload button.
Change-Id: I6dad1585e4c53eeed79cd38316892a7f239d44ef
userextrainfo is a json array that contains
extra user-specific links.
Currently 'avatar' is assumed to hold the
image url for the user's avatar.
'mail' and other links can also be added.
Change-Id: I37c4c68bfa0b7ee659e017b4867dcb8cf5c2ca2f
Reviewed-on: https://gerrit.libreoffice.org/38120
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Earlier, DisableCopy was a misnomer disabling both copy and paste. Now
it only disables copy from the document but allows pasting into the
document.
Change-Id: I8ddfdd493918331276f0656468d3b94c4283fa4d
Turns out this introduces two calls to the CheckFileInfo which is not really
what we should be doing; instead, let's do a kind of cannonicalization in the
WOPI host directly.
This reverts commit ec2fd0844f.
Change-Id: I311bf8a45b706ed9a4d8cd00db0a990ac6d461b4
The docKey creation moved to Storage where we first
invoke WOPI (if/when it's a WOPI-hosted doc and WOPI enabled)
and see if the user has access to the document at all.
If they do, we expect the server to give us a
unique ID to use for identifying the host regardless
of hostname aliases.
If a unique ID is not returned (i.e. empty or missing)
we use the hostname and port in its place as fallback.
This will break hostname aliases, but it will still work.
Change-Id: I407b0087395f9df6ad9cc6e037570487999be4a4
Reviewed-on: https://gerrit.libreoffice.org/37697
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Document broker needs to know when the save request is sent and when the
save finished. It uses these parameters to avoid shutting down document,
in the document broker main polling loop, if save is already going on.
But direct .uno:Save commands issued from
loleaflet precludes document broker to keep track of it - in this case a
.uno:Save command issued from loleaflet followed by closing the
session will prevent saving the document to storage, if document is huge
enough and LO core takes a bit of time to save it. A save wrapper
command, 'save', ensures that document broker is aware of all such save
requests (_saveRequestTime member variable) and doesn't close the
document until we completely save it (to storage and other cleanups).
Change-Id: I5ec73d45adff23b2e7543e93dfd0624a5e5af46d
...but in combination with the appropriate session's access_token to always
authenticate against the same instance of the WOPI host.
Change-Id: Ic94dfa8fcb226a2d134272b22edc1f8f76c24e34
Dung out overlapping return enumerations. Move more work into 'move'
callbacks at a safer time, etc.
Change-Id: I62ba5a35f12073b7b9c8de4674be9dae519a8aca
Not to confuse with the DocumentBroker isLoaded,
this is view-specific. Except for the first view,
which is identical to the document being loaded,
subsequent view loadings are independent from,
though follow, document loading.
Change-Id: I0f21016fa84bf507ca4bc0e7a6c7d0d76b033c60
Reviewed-on: https://gerrit.libreoffice.org/36761
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
If a session is not loaded, it might never
do so. We should skip them when deciding
whether to save using a disconnecting
session or rely on another.
This is to avoid failing to save when
the remaining sessions never really load
the document at all, and are therefore useless.
Change-Id: I4e7127e12960a31e9f66e835bb63fb2347390711
Reviewed-on: https://gerrit.libreoffice.org/36710
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Commit 1e1f23716c fixed this already by
introducing by-value parameters, but
8a1f321c84 broke it. Fix this again, this
time more explicitly.
Change-Id: If29250ac2e99855796935b5cc05ccb222f8a4ad5
Reviewed-on: https://gerrit.libreoffice.org/36436
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Michael Meeks <michael.meeks@collabora.com>
assert()'s are no-op in the release builds, but we still want to see threading
problems in the log at least.
Change-Id: Idb02bb018e8f2d628a57ab570249613ad00bcff2
With this every other client would be able to know about other client's
permission i.e whether they have opened the document as readonly. This
could be important eg: to hide the cursor overlay of readonly users in
the UI or to mark these users as readonly in the userlist.
Change-Id: I5dcb1b4e5a22c9b546d16b69b9216cc7653cff04
Remove locks and replace with isCorrectThread
assertions instead.
Crash recovery still needs some work, but
otherwise tests are clean (91/94 pass).
Change-Id: I9ac3e21854447d19a8e6106487dfd8be00fcf5ef
Since this doesn't necessary mean the document
was loaded completely (as the similarly named
flag in DocumentBroker signifies) rather that
the session was added to DocumentBroker.
Change-Id: Ibfc702bbd111ade2715dcb28ac3aa4e9e8e025dd
ClientSession::onDisconnect might not always be
called. The disymmetry between incrementing in
the ctor and decrementing in onDisconnect always
ran the risk of mismatch and leaking connection
counts, eventually blocking new clients.
Change-Id: I39ec65016984c0cddd0e16cfbf201049ced53713
Reviewed-on: https://gerrit.libreoffice.org/35713
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Sessions are now added to the DocBroker
_sessions map and loaded from the poll
thread first before processing their
messages.
Since messages are not read from the
sockets outside of the poll thread,
there is no reason to queue them
at all. The only exception is when
messages are passed directly
to ClientSession during convert-to
requests. That will be handled
separately (for now convert-to test
fails).
Change-Id: I798166b9e45b5707a33d31137e01a32ce63630b1
Reviewed-on: https://gerrit.libreoffice.org/35705
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Termination should normally be initiated by the
DocumentBroker in question, so sending of termination
message on the sockets come from the correct thread.
When termination happens from elsewhere
(f.e. cleanupDocBrokers) we cannot send socket
messages, and have to resort to rude termination.
Change-Id: I94acb7b314f5dbdc45c57049fc1ac8527ba72fb9
Once a socket has changed ownership to a new
poll it will assert thread affinity with said
new poll. So we cannot do any IO on the old
poll's thread at that point and on.
Change-Id: I662f188dea7c377a18f3e546839ec43f2875dc7b
