Occurs when using the latest LO master branch
the mobile wizard fails:
Util.js:107 Uncaught RangeError: Maximum call stack size exceeded
at String.split (<anonymous>)
at Object.splitWords (Util.js:107)
at NewClass.on (Events.js:20)
at Function.listenNumericChanges (Control.JSDialogBuilder.js:124)
at _formattedfieldControl (Control.JSDialogBuilder.js:1312)
at NewClass.build (Control.MobileWizardBuilder.js:145)
at NewClass.build (Control.MobileWizardBuilder.js:150)
at NewClass.build (Control.MobileWizardBuilder.js:150)
at NewClass.build (Control.MobileWizardBuilder.js:150)
at NewClass.build (Control.MobileWizardBuilder.js:150)
The builder recursive looks like an infinity loop,
and the cause is that the server is not sending the array children
data type.
Change-Id: I298c239b6018a457d3825be886ea22cb984f13cc
Signed-off-by: Henry Castro <hcastro@collabora.com>
The related issue was fixed in:
dc18239d07
Signed-off-by: Tamás Zolnai <tamas.zolnai@collabora.com>
Change-Id: Id0770d11fcaf8eb385b60ddf4286e804127999ca
It does not actually do anything. Font size is not
stored as a 'font-color' attribute.
Signed-off-by: Tamás Zolnai <tamas.zolnai@collabora.com>
Change-Id: I8e39a7c1064bce386c85ff21811fc6f95253adc0
Also, makes the logging of units much less error prone.
The overloaded streaming operators are temporary as
they are provided in C++20. The ones here (though
incomplete) are fashioned after the C++20 specs.
Change-Id: Ieb499282ccb6e63fa939ba07bed3e5a4fbef1bd0
Signed-off-by: Ashod Nakashian <ashod.nakashian@collabora.co.uk>
chrono::system_clock can go back in time.
For time interval measurements, where we don't
care about the local time, a monotonic clock
should be used.
This avoids the server uptime jumping around
with daylight saving (or indeed by regular
synchronization with an atomic clock), among
other cases.
Change-Id: I09f9b24c82d19439348a2e66cad9e9de7d755208
Signed-off-by: Ashod Nakashian <ashod.nakashian@collabora.co.uk>
While chrono supports double as a datatype, it
is opaque and doesn't lend itself to any obvious
units of time (presumably seconds). Using
chrono::milliseconds is much more readable and
also safe when converting from seconds or any
other units. Ultimately, we typically convert
to milliseconds anyway, mostly for logging.
There is but one exception where we convert
in seconds, and now that case is documented.
Change-Id: Ide98f45f2ad8da8225d41ae870bbc4bc09a2a0b5
Signed-off-by: Ashod Nakashian <ashod.nakashian@collabora.co.uk>
No advantage in using int when chrono handles
conversion and comparisons transparently for us.
Change-Id: Idc942e7a2557ef979d876f378cf6bb84d3e657cd
Signed-off-by: Ashod Nakashian <ashod.nakashian@collabora.co.uk>
std::chrono handles unit conversion handsomely
and where there could be logical errors, the
compiler errors out. We only ever need to
use raw integer or double values to interface
C functions and possibly for IO.
Change-Id: I5c2b43c36bd69840f1a4172e9898666c4d68c567
Signed-off-by: Ashod Nakashian <ashod.nakashian@collabora.co.uk>
Now chosen log level is propagated to forkit and kits.
Also, admin console users can filter logs according to their channel names on client side.
Change-Id: Ife15a6148ed87533b81e9d63da252c633e74e559
Signed-off-by: Gökay Şatır <gokaysatir@collabora.com>
A number of call-sites, eg. clipboard, or admin-ws were
writing to sockets assuming they could return all the data
in a single series of writes, without needing to poll. As
such they failed to addSocketToPoll on the new poll - eg.
the docBroker. Unfortunately this meant that on EAGAIN
writes, the socket would be closed and the last parts
of a message lost.
Browsers would give net::ERR_CONTENT_LENGTH_MISMATCH 200 (OK)
The situation is/was intermittent, so painful to debug.
On under-loaded developer machines, socket buffers are larger,
so this was seldom seen.
The re-factor forces a transfer to another SocketPoll via
the disposition, except for a couple of corner cases.
Change-Id: I2f1b2f99f179c4fda84464c9241fe434fa527725
Signed-off-by: Michael Meeks <michael.meeks@collabora.com>
Currently translated at 100.0% (5 of 5 strings)
Translated using Weblate (Czech)
Currently translated at 100.0% (363 of 363 strings)
Co-authored-by: Jan Holesovsky <kendy@collabora.com>
Translate-URL: https://hosted.weblate.org/projects/collabora-online/code-welcome-text/cs/
Translate-URL: https://hosted.weblate.org/projects/collabora-online/ui/cs/
Translation: Collabora Online/CODE welcome text
Translation: Collabora Online/UI
Signed-off-by: Andras Timar <andras.timar@collabora.com>
Change-Id: I4285cb95fda091f0b68db90fdb9b778b0e90f0c7
Currently translated at 60.0% (3 of 5 strings)
Co-authored-by: Daniel de Souza Melo <jxzk@protonmail.com>
Translate-URL: https://hosted.weblate.org/projects/collabora-online/code-welcome-text/pt_BR/
Translation: Collabora Online/CODE welcome text
Signed-off-by: Andras Timar <andras.timar@collabora.com>
Change-Id: Idd9c512623920fee31582f92cc068d7cc231efcb
This reverts commit e1ed5d3c299f2664d108375a5ea3cb90814556a4.
Signed-off-by: Tamás Zolnai <tamas.zolnai@collabora.com>
Change-Id: I9684921837ed6f55a74fb45750bff6c890996a59
The different attributes of a document/user
are decoded when the kit receives them.
Decoding them a second time is usually harmless,
unless, that is, they contain '%'.
After the first decoding the '%' character might
not be escaping anything valid (depending on what
follows it). So a second attempt at decoding
might very well fail and throw, since the escape
code is invalid.
Change-Id: I73d56ce995b0237140a54b6c06bd36bde8b387bd
Signed-off-by: Ashod Nakashian <ashod.nakashian@collabora.co.uk>
I am using the "npm" version 7.0.12, and after
bundling the "loleaflet", the "package.json" is modified.
Let's sort permanently so I cannot get contaminated with
something that I did not touch in my source directory files.
Change-Id: I6a1e6d6b3f1b2898288f06de85fc0307b62cbbeb
Signed-off-by: Henry Castro <hcastro@collabora.com>
