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
This implements a new feature 'OwnerTermination' for WOPI based
hosts. WOPI hosts now have to enable this feature by mentioning
'EnableOwnerTermination' as 'true' in their CheckFileInfo
response. If the OwnerId of the file matches that of the UserId
of the session, this session would be able to terminate all other
sessions currently editing the same document.
The reason for this kind of document termination is sent to all
sessions in a new application-level 'close:' message. This new message is
similar to the CLOSE frame of WebSocket protocol which doesn't
seem to work across all browsers as of now. Eg: Chrome -
https://bugs.chromium.org/p/chromium/issues/detail?id=426798
After receiving this 'close: ' message, loleaflet acts
accordingly and tells the WOPI host why the websocket was closed
via post message API.
Change-Id: I997aa2e7805157ed599a3946a877fd32477cee1b
Abstract all the WOPI related logic in a map handler which is
enabled only if map.options.wopi is set during map
initialization.
Change-Id: I54c5d6eecf33f88e4fd4d2b5ac9e8cf9dd001966
Ping message needs to be echoed and that messes
up reading large messages that come in two parts.
Luckily, it's not necessary to do so as it's
sufficient to poll the state of the socket.
It's true polling is less accurate as there is
a timeout when a socket is disconnected, but
that doesn't seem to be an issue in practice.
Change-Id: I7a5744a621c4416b8f9d003871f6d613cc6ca7dc
Reviewed-on: https://gerrit.libreoffice.org/30705
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
