When we add more server controls (restart, f.e.)
we will need to move this to a separate page.
Also, we need to prompt the admin for reason,
which we can broadcast to all users when the server
goes down.
Change-Id: Ide92e58b5b64a5107b6556aef6b1a88191d5d21b
Reviewed-on: https://gerrit.libreoffice.org/30832
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
CONTROL-C is now handled by WSD only to
have full control over server shutting down.
Also set signal handlers first thing to trap
any early failures.
Change-Id: Ifc5c93b9dd2aef288eed0ed36c600a639dbc6a44
Reviewed-on: https://gerrit.libreoffice.org/30826
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
During tests we need to count the number of
oustanding loolkit processes. Since once a process
dies its parents must first reap it to get removed
from the proc table, we can't assume the process
is fully removed until and unless it's reaped.
In crash tests this becomes critical, since if
we load docs right after intentionally killing
loolkits, we will trick wsd into using a zombie
process. It will then fail at first communication
with the child. While this excercise early failure,
in practice this is unrealistic and will force
handling cases that in practice should not happen
(or when they do, nothing too horrible will happen).
By not counting zombies we can now wait in the crash
tests until forkit reaps the kits, then we test
the scenario where there are no ready children
when documents are loaded.
Change-Id: I0e5ca9a02d215ceca36d80071ba57e9a9c9c3240
Reviewed-on: https://gerrit.libreoffice.org/30813
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Unfortunately it turns out that POCO's handling of the non-blocking case is
wrong when EWOULDBLOCK is returned from ::send(). This leads to a situation
when part of the data has been sent, but it is impossible to send only the
rest of it, because of too high-level api for the websockets.
We could essentially re-implement the POCO's websockets and use just the lower
levels of POCO - but then it's a question whether it is actually easier to use
the Linux system calls right away :-)
Change-Id: Ied08f68d5037d0ab9ca8266cd20e1084bcebfd14
Accessing the parent iframe, atleast on my local box, where
parent frame and loleaflet frame have different origin, is not
allowed by browser security policy.
Change-Id: Ia3a356fa1d8a81f38bbc27d256471302be8b6729
WOPI hosts can now send above mentioned messages to loleaflet so
that loleaflet does stuff accordingly.
Change-Id: I50e10a62c5b629bd12f7d9ce51bcd13cb13cdd8a
Add more WOPI extensions for this - HidePrintOption,
HideSaveOption, HideExportOption. Setting HideExportOption to
'true' in WOPI CheckFileInfo response would hide the 'Download
as' option from the File menu.
Change-Id: Ia2259ee9525cc6c4331a52e2221af4df188eab07
It looks like that the implementation details of POCO are thread-unsafe when
in non-blocking mode, and that is even when the actual sending of the frames
is guarded by a mutex.
Needs more research; but for the moment, enable non-blocking mode for HTTP.
Change-Id: Idcce3fb55bae73c17d9fc321a2273256c0396664
sendFrame() implemented in LOOLWebSocket is thread safe, and also deals with
large messages - sends the "nextmessage: size=..." frame before the actual
large frame.
The problem this is attempting to solve was that when sending a large frame,
it was split to multiple packets. During that, another frame was sent from a
different thread; which lead to confusion, and the resulting frame was
corrupted (because it ended up composed from unrelated packets).
Change-Id: Ie85952e431b1cad2fdc6e3c64df8a444ea0ae971
