Because POST requests need to consume the complete
request message, we shouldn't clear the buffer
before handling the POST request.
Change-Id: I53f7b664378dd6614afc6983fdd10d0102b38acf
Reviewed-on: https://gerrit.libreoffice.org/36763
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
We should only remove sessions that had already been
disconnected, which caused the saving.
Change-Id: I22fc54356af50df7a7bd2107fa17f6951d40812f
Reviewed-on: https://gerrit.libreoffice.org/36762
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
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>
Passive clients that don't load the document can
be disruptive as they are not useful for saving
the document, so we need to ignore them and
use reliable sessions.
Change-Id: I162ec00823ba5af776fcb55f6d58149f2a56d7bb
Reviewed-on: https://gerrit.libreoffice.org/36712
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
When a session is disconnecting and we use it to save
(because the other sessions are not viable for saving),
then we need to correctly detect if by the time
saving is done there are no other sessions left.
Otherwise, we end up thinking there are other sessions
when the others had been disconnected during saving.
Change-Id: I55687376f5237a495ae163b53f51ee1d2414d770
Reviewed-on: https://gerrit.libreoffice.org/36711
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>
.repeat is not supported.
Change-Id: I4f9d75f851f73e4cc626ca6f0a13aa1877308e70
Reviewed-on: https://gerrit.libreoffice.org/36553
Reviewed-by: Henry Castro <hcastro@collabora.com>
Tested-by: Henry Castro <hcastro@collabora.com>
Make this overlay interactive, but we don't want to color this overlay
since LO core already colors redlines in tiles for us.
Change-Id: I46077f5b6a28cdd492325b8ab3014fb25ecd94ec
Make comment overlays clickable and when clicked select the
corresponding annotation. Also deselect when clicked where there is no
comment overlay.
Change-Id: Id9236862eec86b7508978ad8fe803455e03adbe2
Create the new L.PosAnimation object everytime you want to animate, not
just use the same everytime which has the limitation that animation
doesn't happen simultaneously.
Change-Id: If5f63702afe0fee7f44c8cf4605179d68de289e8
This slows things down terribly, particularly the setting on the websocket
made tiles appearing one by one. Let's keep the possibility to zero the buffer
sizes for debugging, but hide that behind an env. variable (and in debug
builds only anyway).
Change-Id: Ie4d2cdb3c0ec3c50f1a2b4f9941a462ac4f2d196
This is rare and should take a few short seconds
to save and then we can load as normal.
Since the client auto-reconnects anyway, no
need to tell the user to try again.
Change-Id: I51a7ad207edec3203933a1808288870e69699952
Reviewed-on: https://gerrit.libreoffice.org/36655
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
The server correctly saves all documents
and waits to upload them before exiting.
Change-Id: I04dc9ce588bc0fa39a9deb298d0a5efa61a03f1a
Reviewed-on: https://gerrit.libreoffice.org/36654
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
A Document has its own snapshots set.
A snapshot is a string representation of a JSON object.
AdminModel keeps also the expired document objects.
Query each document object in order to get their own history.
Admin accepts an "history" command then returns a json object.
An administrator checks the history by dashboard.
Change-Id: I73c87eff334cdb5a4a58043b2b66f18a56240b3a
Reviewed-on: https://gerrit.libreoffice.org/35926
Reviewed-by: pranavk <pranavk@collabora.co.uk>
Tested-by: pranavk <pranavk@collabora.co.uk>
When calling the cleanup from DocumentBroker::destroyIfLastEditor(), it might
be (theoretically) too early; so let's do it safer - as the last thing when
shutting down the DocumentBroker::pollThread().
Change-Id: Idc5e34b36d524c8f87a3a0fc99c87244e9784abf
Client now sends setclientpart only when it wants to change
the current part number, but not when it is updating
the current part when it receives setpart from the server.
When switching parts (either by the keyboard or mouse)
LoKit sends a notification of the current part and
invalidates tiles. As a reaction to that the client
cancels its tiles and requests new tiles for the
new part. In addition, it sends setclientpart
back with the new part number.
This works fine, except when the client switches
between parts quickly (as when randomly pressing
page-up and page-down quickly in impress), by
the time LoKit receives the second request the
client would have reacted to switching the first
by sending setclientpart for the first. This
will result in a resonance back and forth ad
infinitum (or when the client goes inactive).
The client shouldn't echo back the part number
which the LoKit has told it (it should only send it
to explicitly set it itself). But the server should
be smart enough to remove duplicate setpart
notifications from the client queue. This reduces
the chances of an ocillation like that to happen.
Change-Id: Ia8a1bb25e427ab910129340ce599e3743983463b
Reviewed-on: https://gerrit.libreoffice.org/36598
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
When switching parts (either by the keyboard or mouse)
LoKit sends a notification of the current part and
invalidates tiles. As a reaction to that the client
cancels its tiles and requests new tiles for the
new part.
Since the response to setpart is a large number
of tile cancellation and new requests, the
cost of setpart is significant (esp. with large
number of clients). To avoid that, we de-duplicate
setpart entries from the client queues so there
would be only at most one setpart (the last)
queued to be sent to the client. This minimizes
the unnecessary noise when the part changes
faster than the server and/or network can
keep up.
Change-Id: I87578004203acc63d43e6d398ca04e37f766d9ba
Reviewed-on: https://gerrit.libreoffice.org/36597
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Retry up to 10 times with a delay of 1 second in between.
Also, show the user a message (after first reconnection
fails) that the document is unloading to try again
(but of course we auto-retry anyway).
Change-Id: I616d7643f146a6d5b7ccda7bb2aa567e3a9efe47
Reviewed-on: https://gerrit.libreoffice.org/36596
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Without an explicit WS message, the client
does not get this message and the handler
is not invoked at all.
Change-Id: I71e210a9958965cff35dd4d0f1d99985429b82f4
Reviewed-on: https://gerrit.libreoffice.org/36593
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
This box-shadow interferes with direct comment children and breaks the
root-children comment block UI. Lets remove the shadow for now.
Change-Id: Idda659bcfca76093c148400b2ab311bc39861e84
Change the layouting algorithm to check for comment relationship and set
the layout bounds accordingly.
Change-Id: I67cc32092d8cf2c1bbc0d677258387739bfc638e