Because the new-style tests are intrustive,
the exception that CppUnit throws on assertion
failures is caught and processed with the
application logic, which is far from ideal,
because it's very difficult to find the
cause of failure.
What we'd like is a way to control what happens
when an test assertion fails, such that we can
properly log/print the failure, and even break
in the debugger.
The new macros allow us to control the behavior
at compile-time and have added flexibility.
For now, they log an assertion failure before
invoking the CPPUNIT macro, and support a
compile-time directive to assert, which is
useful for breaking in the debugger.
Change-Id: If464ba246e3ec747f31496a4215cb73ef735dfaf
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/87625
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
The bulk of this commit just changes std::vector<std::string> to
StringVector when we deal with tokens from a websocket message.
The less boring part of it is the new StringVector class, which is a
wrapper around std::vector<std::string>, and provides the same API,
except that operator[] returns a string, not a string&, and this allows
returning an empty string in case that prevents reading past the end of
the underlying array.
This means in case client code forgets to check size() before invoking
operator[], we don't crash. (See the ~3 previous commits which fixed
such crashes.)
Later the ctor could be changed to take a single underlying string to
avoid lots of tiny allocations, that's not yet done in this commit.
Change-Id: I8a6082143a8ac0b65824f574b32104d7889c184f
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/89687
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
This started to reliably fail for me recently.
I think the problem was that deleteAll() also listened for incoming
messages, so while waiting for textselection:, perhaps it processed (and
ignored) invalidatetiles:.
As a consequence, once deleteAll() returned and testUnresponsiveClient()
started to wait for invalidatetiles:, the test may or may not failed,
depending on the order of messages.
Fix the problem by just dispatching the SelectAll and Delete commands,
then waiting for invalidatetiles:.
Change-Id: I33f096e7dcb7f9daf1968dcb50d8a5f53824f5bd
Sometimes core renderes with sub-pixel differences
(the crosshair at the corners of the Writer pages
show line anti-aliasing differences). This causes
failure of the tests that count the tile deduplication.
We now tolerate when we get an unchanged tile twice,
assuming it was due to such a rendering difference,
but we re-trigger another change and this time we
don't expect any extra tiles, no more than two
variations of the anti-aliased crosshair was
observed.
We also move some duplicate code into utility
functions to improve readability and reuse.
Reviewed-on: https://gerrit.libreoffice.org/81196
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Tested-by: Andras Timar <andras.timar@collabora.com>
(cherry picked from commit 9603597fd1aaecb27893792cfd2d243e450b58b8)
Change-Id: I1a66732dd3443bfbd770d8dc65721571dfa08615
Reviewed-on: https://gerrit.libreoffice.org/81572
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
When polling for tile messages, the last wait
(which will timeout) by default will be 10 seconds.
This is too long to make the tests fast enough, and
also results in the internal cache from evicting
tiles in some cases.
Reviewed-on: https://gerrit.libreoffice.org/80897
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Tested-by: Andras Timar <andras.timar@collabora.com>
(cherry picked from commit e173427bd9ca5939339994180f5b51ea11393050)
Change-Id: I6c2b80022ffcef2b21c99dd57bca61e7daaadc86
Reviewed-on: https://gerrit.libreoffice.org/81568
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Michael Meeks <michael.meeks@collabora.com>
The part number in case of writer has no actual meaning, since
for writer we have only one part (the whole document).
It seems the code is not consistent in that it is 0 or 1.
Change-Id: I9e56079f7861f7e0d5794e6f711045cd9448dfa7
Reviewed-on: https://gerrit.libreoffice.org/79851
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
Added functions to get file timestamp and to convert
chrono timestamp in ISO8601 fraction format and some
test cases.
Change-Id: I58961a31f7262b367cff9f33cffdec7571a2f8f7
After commit 8e118889cb (wsd: leaflet:
support statusupdate: messages to sync clients, 2019-08-17), which added
a new hiddenparts= key, but forgot to adapt tests accordingly.
Change-Id: Ia5baefff37b88f5b173d65ae80a126f94b420cb0
Saves lots of string construction and storage, simplifies lots of code.
Store the more exotic font-caching bits etc. in a separate store: we
should also pre-render these really and share them.
Change-Id: Icaeff8fd72f52d7215c06a687b1e39cfb7631503
Remove significant complexity; if we need it later lets do it more simply
serializing when we start / finish a session.
Turn off caching for mobile - possibly should kill for single-user too.
Change-Id: I5ea56088ddbb61f22fe7920f8c9ac7440cb3296a
We try to decrease the network usage with avoiding sending out
to much tiles to the client. When we already sent out two versions
of the same tile without having the tileprocessed message from the
client we delay sending out the next version to avoid spamming tiles
on the network.
Change-Id: Ia47cd7c0d3fb829f6777f0c3265970433591df19
It's good if this limit big enough to send all the tiles of the
current visible area at once, so the tiles arrive at the same
time to the client by zoom or scroll. Now this value is set to a bit
bigger so if we have a small amount of tiles before zoom / scroll we'll
still see the same on the client side.
Change-Id: I8e28dbf6197fe2f683fe9528e9a32c15a191b20e
Some times tiles with the same wireID survives the wireID
filtering in kit, so we should do that in wsd too.
The issue is with the tilesBeingRendered construction. First when
one tile is filtered out on kit side the client remains subcribed
to the tile, since wsd does not know filtering happened.
Second via the tilesBeingRendered object more clients can be subcribed
to the same tile and so when one client request a new version of this
tile (with an old wireID) the rendered tile is sent to all subscribed
clients even if the other clients has up-to-date tiles.
Change-Id: I4ca6b7a83a5d6979a9f924d766a71aba5e5362c7
Since this commit:
9473908d45
We can avoid that, because the tiles will be invalidated
on the client side and when the client visible area changes
the invalidated tiles are requested anyway.
Change-Id: I272e3b4b87380ae574c16a2b480dbc8caabf4b32
When we're doing the prerendering we also need to register
a tileBeingRendered object, so we know that the given tile
will arrive soon. In earlier version of the code, rendering
and sending of the tile was not separated in time, but now it is,
so we need create a tileBeingRendered object even if we don't
subscribe the client to it yet.
Change-Id: I1374c22e5ffebe1d6fcc6e37261ddcedeb9066ec
It's seems unstable. After canceltiles wsd still can send tiles
if they already in the senderqueue.
Change-Id: I28f669aa18dfbfee1d9d242bd1ee3d0490f06c68
With the new code, wsd is waiting for tileprocessed messages
if the upper limit of tiles-on-fly limit is reached. To avoid that
send canceltiles message.
Change-Id: Iadf16c834f12d14000d630078882dfa8e11a99a0
And improve the logging support in unit-tests to
help troubleshoot issues faster and more accurately.
Also makes the code more readable (hopefully).
Change-Id: I4f8aafb5245e2f774b03231591a74544f9ec84aa
Reviewed-on: https://gerrit.libreoffice.org/48645
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
When there are many views requesting tiles,
disconnecting any should not cancel tiles
for other views.
Change-Id: I6029432c4b9ab931811dcb3b03b0441b413a9971
Reviewed-on: https://gerrit.libreoffice.org/32872
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
