Invalidation for spreadsheet and presentation
are part-sensitive. The handler will take
care of this distinction and construct the correct
invalidate command.
Also, set active flag before firing invalidation.
Change-Id: I9e897750e0768b54cc1521d47d69b5dbb1a36244
Reviewed-on: https://gerrit.libreoffice.org/24779
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
The handles imply (and indeed are designed for) changing the
selection by dragging them around. Viewers can't change the
selection, so no reason to give them the selection handles either.
Change-Id: Ifa793ac982fd48be877e7ed7709f70890d8de194
Reviewed-on: https://gerrit.libreoffice.org/24770
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
This message is already sent from CalcTilelayer.js.
Change-Id: I9f84d5f365dbfea38061e206d5d52e2201be22ed
Reviewed-on: https://gerrit.libreoffice.org/24769
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Make sure to sync both lokit and viewers as to which
part is being edited when a previously-viewer takes
editing.
Change-Id: Ia70f647a26029447bb4360633f79233fa9596059
Reviewed-on: https://gerrit.libreoffice.org/24768
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Relying on the filesystem to tell us when the document
was last modified (to decide whether to upload to storage or not,)
proved unreliable.
Now we always upload to storage if there is only one client.
This both minimizes the risk and also avoids the file timestamp
check as a workaround to the problem of re-uploading documents
as many time as there were clients. Since with one client we
can only upload no more than once per save, which is reasonable.
Furthermore, when a client disconnects we auto-save automatically
as a matter of precaution. However, when there are other clients
still connected, we don't wait for the save to complete, rather
we let that job to the very last one.
Change-Id: I94a2e4bddaed30a6c9c0e69f8006667d33c5b8ee
Reviewed-on: https://gerrit.libreoffice.org/24767
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Invalidation messages already contain the part they
are referring to (with the exception of EMPTY).
Sending clients the current part makes it hard
to let clients view different parts of a doc
while an editor types.
It also implies that the part has changed,
which isn't necessarily true. If it is, a
separate curpart notification will be sent.
Change-Id: I49afcebef8994c892ef8be633d3ce3982b031d2b
Reviewed-on: https://gerrit.libreoffice.org/24750
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
WSD server must be up and listening to incoming
connections before firing up ForKit and spawning
children.
Having the order reversed caused tests to fail
randomly when WSD was slow to listen to incoming
connections from children already initialized.
Change-Id: I4eaf4a658c65da024101efc096c39222ebfa3c00
Reviewed-on: https://gerrit.libreoffice.org/24745
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
This prevents deadlocking in case of test failure.
Change-Id: I3026311e9a67543a26acb0316546e6b5aacf61dc
Reviewed-on: https://gerrit.libreoffice.org/24738
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Also, don't let these tile previews change part of the document
permanently. This is a temporary solution till we have some
better API from LOKit to deal with such a situation.
Change-Id: I8dfefd2b7ad8cf3e7a57afb95b57994ef0bb3b6c
editlock= is always the last parameter. This fixes the slide
previews in impress documents for editing session.
Change-Id: I3531c7f52e09e655524fa0afd6fe66da504b5d70
Obviously this is dangerous, since the id is not part of the
subscription key (the filename) so different clients could
have different ids on the same part, but in practice I
expect this not to happen. Though that clearly depends on
how clients use the id.
Change-Id: I52a0b043c9b5e5ad1111b692e4216cc9ffec5b2b
Reviewed-on: https://gerrit.libreoffice.org/24680
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
bccu#1433, bccu#1757 related.
Piggyback editlock information to tile messages so that kit can
use that information to allow changing parts only for messages
with editlock.
... and decline tile render request for tile messages without editlock
information
Change-Id: I9cedb870cd977741375665cb258d04c818481a14
The tile and tilecombine messages apparently have optional
appendages at their rear ends. Not one, but two (at least).
While the first (timestamp) seems to be truely optional
(in the sense that leaving it out doesn't break anything,)
the same can't be said of the second (id).
For Impress slides this id is used to identify the slide
to which the tile belongs. Or rather the slide being
rendered, as it seems meaningful only for the slide
thumbnails.
Previously the complete arguments of tile were copied
verbatim from the input to the output (i.e. back to the
client) and so any extra payload was also echoed back.
But when id is missing (when expected) loleaflet not
only fails to show these tiles (understandably,) but
it also fails to show the scrollbar for said slide
thumbnails altogether!
With the new logic to move the tile communication to
the child socket instead of the clients, the arguments
are parsed and then serialized back in the response.
So all fields must be explicitly known in advance.
This change is necessary because tilecombine is broken
to tile commands and so both share common code. This
means that echoing back the request verbatim will
break loleaflet since tilecombine arguments (which
is a list) is not a valid response (which has the
format of tile). So the internal representation
has to be something neutral/common.
The fix is to parse the timestamp and id only when
provided and to echo back the id only in that case.
Change-Id: Ic97cf0de4083d412a4b3543e8b9a8713ac27a27c
Reviewed-on: https://gerrit.libreoffice.org/24669
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
For the moment, it will allow running 'make check' that does not conflict with
an already running loolwsd (eg. from 'make run'). Later we can consider
running more tests in parallel.
So that they can run in parallel to a 'production' loolwsd (like one from
'make run' or so) in the future; for the moment it is not possible, as the
MASTER_PORT is hardcoded.