using these WOPI protocol extensions: DisablePrint,
DisableExport, DisableCopy. All assumed to be false if not
provided.
Change-Id: I415597d710107f9d8cbb8757f361365cc2a88eb1
We want document owners (sessions with their WOPI UserId =
OwnerId) close the document (for all sessions) only if
EnableOwnerTermination property is specified. Note that
EnableOwnerTermination is an extension to WOPI, and not part of
original WOPI standard.
Change-Id: I7237d172c4c54477572bc132336910250af075a3
If the socket is in error, SELECT_READ returns
immediatly as failure. In this case we sit
in a tight loop polling read over and over.
We now check for SELECT_ERROR when SElECT_READ
fails to properly close the socket and break.
When receiveFrame returns -1, we should first
check the flags for socket close, as that
is a legitimate case of returning -ve.
Change-Id: I7bbc948638a8395d28990ba92eddb9a1a9f1e6f2
Reviewed-on: https://gerrit.libreoffice.org/31932
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Top level make would now build loleaflet too if necessary.
Respect value of ENABLE_DEBUG and if present add debug-info to
generated js bundles too.
Add new rule, clean-local in loleaflet.
Change-Id: I3a9b727824f2877fc72719a8bfdeebed5448cb7d
This always takes ~2 seconds irrespective of whether node_modules
needs updating or not. Lets add appropriate dependencies and save
these precious 2 seconds.
Change-Id: Ided4ff334316c16521e5ea7a69d15736a1cc170f
Use events, 'hidebusy', 'showbusy' to interact with toolbar.
In some cases, it may happen that w2ui usage in loleaflet happens
before browser loads w2ui.js (as it is in <script> tag after the
one which loads loleaflet).
Change-Id: I9b1b249ede72ed01f97cf31fd3f93780312530bc
The pool is checked for expansion before processing
items from the queue. By tracking the number of idle
thread (i.e. not currently sending data) we ensure
that there is at least one idle thread before
we invoke the socket.
If there is not enough idle threads at that point,
a new thread is spawned, so long as we're below the
limit. This guarantees that even if all the active
threads block on the socket, we'd always have one
more to process new data (until we reach the limit,
which is as many client connections as we have).
Technically, a single slow connection could
still monopolize all connections if there are
many messages to be sent to it. For that we'd
need to track and assign one thread per connection,
something we don't currently do.
Change-Id: Ic8b5e064da068b37bcfa773005495b198763c31d
Reviewed-on: https://gerrit.libreoffice.org/31886
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
This adds SenderQueue and a wrapper of messages to
send back to clients.
Currently no threading takes place, but the messages
are pumped through the queue nonetheless.
Change-Id: Id9997539c0a2a351cbf406f649c268dd3643e88e
Reviewed-on: https://gerrit.libreoffice.org/31883
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
No point in building things that are already built, create
different jake tasks, enclose whole of the build process in a
single jake task - 'build' which would call other various tasks
depending on whether they needs building.
Change-Id: I4b26834440ef638d697aa0793d2ced1e2c49784a
Compression is most expensive in terms of time; if we detect
early that there are no changes between oldSrc and newSrc, lets
return early and skip the compression.
Change-Id: Id3d7c1d4bf89a33819907ff735e01629581627a3
Start searching as you type
Press enter to search forward
Shift + enter to search backwards
Esc to get back to editing
Change-Id: Id366069aea9eb0e96e8d73fa4b57f972b0ce78e5
Use a new protocol message, 'resetidle' to inform Admin clients
whenever a user has done anything in a document view. This is a
message that Admin clients need to subscribe to.
Also add the current idle time for each document to the 'documents'
message.
To reduce protocol chatter, the idle time is updated at most once per
10 s.
Change-Id: I418e82b05048a3628f21dcd240ccd974b3a01356
Reviewed-on: https://gerrit.libreoffice.org/31653
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
