Age | Commit message (Collapse) | Author |
|
Regression from 2157a3536f97ff5ae7c82611a801fef7e3708983
sfx2 store: try rename before copying
Rename is cheaper then copying the content over manually, so try that
first.
On Windows, we need to keep the file's dentity, including metadata (e.g.,
creation time, which is kept in FS). WinAPI has ReplaceFileW specifically
for this, and it keeps ACLs of the original file, and otherwise makes the
changed file not a separate entry, but updated old file from system's PoV.
Eventually, we could try to restructure creating backup copies (e.g., for
documents when configured so) to take advantage of this function being able
to do that.
Change-Id: I6001a2a3af5e10bc010f5ef129f4bb6f83ee1581
Reviewed-on: https://gerrit.libreoffice.org/60163
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins
(cherry picked from commit c9343988204ee3e9889f3cc833adbbaca83e53e6)
Reviewed-on: https://gerrit.libreoffice.org/61041
|
|
...with new configuration option --enable-cipher-openssl-backend
rtl/cipher.h (which is part of the stable URE interface) offers functionality to
en-/decrypt data with Blowfish in ECB, CBC, and streaming CFB mode, and with RC4
(aka ARCFOUR; which is a stream cipher). LO itself only uses Blowfish CFB and
RC4, so only those are wired to OpenSSL for now, for simplicity. Using Blowfish
ECB and CBC, or Blowfish CFB in DirectionBoth mode would cause failures for now
(cf. sal/qa/rtl/cipher/rtl_cipher.cxx); the assumption is that no external code
actually makes use of this functionality.
Using NSS instead of OpenSSL could be an alternative, but there appears to be no
support in NSS for Blowfish in streaming CFB mode, only CKM_BLOWFISH_CBC for
CBC mode.
Change-Id: I0bc042961539ed46844c96cb1c808209578528a0
Reviewed-on: https://gerrit.libreoffice.org/59428
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
(cherry picked from commit 4bc16aeb73c1201f187742e0fefe35521fae77ac)
Reviewed-on: https://gerrit.libreoffice.org/59575
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I011f4cbb10324c4a7d4e1be3ab1355291f79730b
Reviewed-on: https://gerrit.libreoffice.org/57840
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
LibreOffice uses its low-level API to look up files inside the app
bundle thousands of times, all the time, and especially when starting
something. Both when the process starts, and when a specific aspects
of the application starts (like after typing a first character into a
Writer document in a session). Having all those, too, go through this
alias (bookmark) resolve dance is just insane. There won't be any
aliases (bookmarks) there.
This shaves almost a second from the delay after typing the first
character into a Writer document in a session. There is still a
noticeable delay left, though, likely mostly caused by Python
(Lightproof) initialisation slowness. (It's cross-platform.)
I would say that it is a bit questionable whether the
macxp_resolveAlias() functionality is worth it at all, even.
Change-Id: I2461141c6b58738befd0db4902eb25e63b788b79
(cherry picked from commit 3b6905e37a6baac08eaff00e6e42aced7d6896df)
Reviewed-on: https://gerrit.libreoffice.org/56122
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
|
|
Once an in-process JVM is instantiated, it is vital that the disposition for
SIGSEGV is not changed afterwards, as we do not make use of Java's libjsig.so
(cf. <https://docs.oracle.com/javase/8/docs/technotes/guides/vm/
signal-chaining.html>) in our processes.
I observed sporadic SIGSEGV crashes of CppunitTest_dbaccess_RowSetClones on a
64-core aarch64 machine (see comment at <https://github.com/flathub/
org.libreoffice.LibreOffice/issues/42#issuecomment-395731088> "OpenJDK 10 is now
available"). What apparently happenes is that the cppunittester process first
sets up its signal handlers through vclbootstrapprotector, which doesn't set one
for SIGSEGV because bSetSEGVHandler is false in sal/osl/unx/signal.cxx because
!is_soffice_Impl(). Then later when the in-process JVM is instantiated it sets
its handlers, including a SIGSEGV one. Towards the end of the process,
DeInitVCL calls osl_removeSignalHandler calls onDeInitSignal, which erroneously
resets the SIGSEGV handler because it doesn't honor bSetSEGVHandler. But it
can apparently happen that JVM threads are still running at that time and are
executing JIT'ed code that can cause SIGSEGV that relies on the JVM's handler
being installed, which it no longer is.
(This can probably also happen for soffice.bin itself, where bSetSEGVHandler
will be true. That will need a different, follow-up fix.)
Change-Id: Ib6d99c23e57daa0b7576964908aadff511f2bb21
Reviewed-on: https://gerrit.libreoffice.org/56232
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
(cherry picked from commit 6417e8cda329116f0d61e0d5e55fa78207b6148c)
Reviewed-on: https://gerrit.libreoffice.org/56242
|
|
Regression from
commit 9a6527a98fb968b3fe6bc293ff7520a9480d43d0
CommitDate: Mon Jun 27 21:57:52 2016 +0200
stringToDouble() do not parse separator without digit as 0.0
Change-Id: I9d90aedc324ef0938297224297d89817e3fd1e90
Reviewed-on: https://gerrit.libreoffice.org/56028
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
(cherry picked from commit 5c0783cecb0b141885a25ca26220614ad3125f8e)
Reviewed-on: https://gerrit.libreoffice.org/56043
|
|
Still some holdouts from that bad old habit it seems.
Change-Id: Ib0fe2c7eb006649b121668c549ff8e0bb060e120
Reviewed-on: https://gerrit.libreoffice.org/55331
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
(cherry picked from commit 92ed91610d30246e671226da081da748f6b16aae)
Reviewed-on: https://gerrit.libreoffice.org/55341
|
|
Change-Id: I39803413533ae5b291d2e1abf4aa1bfe1f5900b5
Reviewed-on: https://gerrit.libreoffice.org/55268
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
(cherry picked from commit 423d01ec92a2c99ca8309a78f6763478e299f6a3)
Reviewed-on: https://gerrit.libreoffice.org/55321
|
|
Change-Id: I625b73152c0c277c6e0ce3e24e4704094fc4e8ff
Reviewed-on: https://gerrit.libreoffice.org/54822
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
(cherry picked from commit 96d7c67d98527b1ccc1cfba3ca817238e582d63b)
Reviewed-on: https://gerrit.libreoffice.org/54943
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I5ad14286712e27e8d15174c9ed420bf93367d041
Reviewed-on: https://gerrit.libreoffice.org/54579
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
...that ignore the out-parameter integral part
Change-Id: I05f07c1a8909023232f8aecf75ea5541d4eb81ca
Reviewed-on: https://gerrit.libreoffice.org/54474
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I63dbf18f144a792ae775fe6706da81657f790016
Reviewed-on: https://gerrit.libreoffice.org/54416
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...where the other half introduced with 1b12d5ecb1be36267534e0b980d7c53d50645511
"Work around GCC 7 mis-feature" has now been removed with
6da400912e8c69ae86650e799767da54ee422392 "[API CHANGE] Remove no longer working
rtl_arena -> rtl_cache feature"
Change-Id: I79b71d119848150c0ebd2244f0ace08609fd17e9
Reviewed-on: https://gerrit.libreoffice.org/54417
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
rtl_arena_create's quantum_cache_max parameter (when non-zero) would have
allowed an rtl_arena to internally use an rtl_cache for chunk allocation. (And
none of the LO-internal uses of rtl_arena_create makes use of that.)
However, with the combination of old ce906b8096081dee15dc8cc96e570d5b0b587955
"skip tricky allocators on G_SLICE=always-malloc" and recent
bc6a5d8e79e7d0e7d75ac107aa8e6aa275e434e9 "Disable custom allocator", rtl_cache
unconditionally just uses malloc/free now, so the rtl_arena_create
quantum_cache_max feature has effectively become irrelevant. As those changes
appear to have no negative consequences overall (and help remove quite a chunk
of no-longer used code), leave it at that and officially abandon the
quantum_cache_max feature.
Change-Id: I7d186a4a1589db6a73059c2be164aa81d81aef47
Reviewed-on: https://gerrit.libreoffice.org/54388
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
|
|
This reverts most of commit 4c5b4752786ae2c174cd8fa8aa42b27a0994f34a
and just keeps the OutputDebugStringA() call unconditionally.
Change-Id: Ia838052b3147ca2d66c7d28b04eadd9700244669
Reviewed-on: https://gerrit.libreoffice.org/54029
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Ic8fea70fd3b0b2d4881cd30e3616f5bbf7c0c533
Reviewed-on: https://gerrit.libreoffice.org/53776
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
Change-Id: I966dcf87be021520e7cc394338b9c0574bb8afee
Reviewed-on: https://gerrit.libreoffice.org/53541
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ia58d8950b3b9e48bbe9f075b9fe1eed62d9abf0d
Reviewed-on: https://gerrit.libreoffice.org/53188
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Reduced the scope of some variables in source.
Change-Id: I705e7f2587fd81015f06fb301eb8d4a270668d73
Reviewed-on: https://gerrit.libreoffice.org/53042
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Gökhan Gurbetoğlu <gokhan.gurbetoglu@pardus.org.tr>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I20b5cfe2fd95da3f37a6812af5683bcc4d918b06
Reviewed-on: https://gerrit.libreoffice.org/52882
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Iaa3adc54d547e243b977a562fa4dbc2b9b9c6592
Reviewed-on: https://gerrit.libreoffice.org/52905
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Muhammet Kara <muhammet.kara@pardus.org.tr>
|
|
https://www.gnu.org/software/make/manual/html_node/Text-Functions.html
Change-Id: Ifb1d92cd9c7b59360d296026f01aa54ed83ed9c3
Reviewed-on: https://gerrit.libreoffice.org/52604
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Also, order them alphabetically.
Change-Id: I144331d71455c1c794d300f9a4f4e2e21fcd5e1b
|
|
Change-Id: I99ec6176c0876b948e35880f02d54905d26e7280
|
|
This prevents from e.g. com.sun.star.bridge.UnoUrlResolver's
emitting confusing messages, when trying to connect to a port
on which no LibreOffice process is listening, like:
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> __main__.NoConnectException: Connector : couldn't connect to socket (Success)
^^^^^^^
After applying this patch:
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> __main__.NoConnectException: Connector : couldn't connect to socket (Connection refused)
You can see the above behavior with the following python code:
import uno
x = uno.getComponentContext()
y = x.ServiceManager
z = y.createInstanceWithContext("com.sun.star.bridge.UnoUrlResolver", x)
url = "uno:socket,host=localhost,port=2002;urp;StarOffice.ComponentContext"
a = z.resolve(url)
... provided that no process is waiting on port 2002.
Change-Id: Id094cf9271fe77d84f2284d91a0e452448de2bc2
Reviewed-on: https://gerrit.libreoffice.org/52018
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Iacb9332635cb6afa90ec1a72e96388b3b5b7b56c
Reviewed-on: https://gerrit.libreoffice.org/52420
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I162993df6b802bd51e4e079b3dc530476b220e4e
Reviewed-on: https://gerrit.libreoffice.org/52325
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This reverts commit bdbb0d1cc13a11c8c857ee2d387771a8c2622488. Assumed to no
longer be necessary after 9906c6d2a55b6f8a27903f0ef08aa8949d7a71c2
"rhbz#1559633: Treat EPERM same as EACCES when opening files".
Conflicts:
sal/osl/unx/file.cxx
Change-Id: I9f7ef544da3fec00810cd1d55bb52bf0470d1054
Reviewed-on: https://gerrit.libreoffice.org/51979
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
...when some other entity creates it in parallel. This used to stop creating
any subsequent sub-directories in the chain, and instead return a misleading
osl_File_E_EXIST.
I assume this is the underlying issue of the sporadic Jenkins "Daily Screenshot
Build on Windows" failures. (After the previous attempt at getting at that,
d15ff312ad80e4d1f210636e3374a81c14c229a2 "Normalize computation of directory and
file-in-directory URLs",
<https://ci.libreoffice.org/job/lo_tb_master_win_screenshot/333/console> now
failed for a different file after all,
workdir/screenshots/modules/schart/ui/datarangedialog/DataRangeDialog.png during
CppunitTest_chart2_dialogs_test.)
Change-Id: I00ee67c1ef634c5390c677693e143c26266eeda7
Reviewed-on: https://gerrit.libreoffice.org/50892
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I16a77d0701b42bcf9d751834f0eae4decedd9176
Reviewed-on: https://gerrit.libreoffice.org/50858
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
* Obviously VCL wiring is missing, but most components do build.
Change-Id: Ie853ada1423a8f4c2b647be59cd47a7730c42978
Reviewed-on: https://gerrit.libreoffice.org/50293
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
|
|
...as used by solenv/gbuild/UITest.mk
Change-Id: Iefc1c1dc2f775c6872a5075a16e049f00d60273a
Reviewed-on: https://gerrit.libreoffice.org/50618
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...which relies on division by zero producing inf, for atanh(1) = inf. (As
tested by CppunitTest_sal_rtl.)
Change-Id: I0e5de8850ab4cbd05f83027c1eb548e2e0c9a9b2
Reviewed-on: https://gerrit.libreoffice.org/50613
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ie1cff6b690e69d23c16a1a60ef4271d6cf48c13b
Reviewed-on: https://gerrit.libreoffice.org/50260
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
When installing an extension e.g., paths can get very long and they
hit the 255 char limit, thus the installation fails.
So we need to prefix the path with the long file name prefix
when its longer than MAX_PATH for windows api calls to succeed.
Change-Id: Ie62644192ba40a9d4802772cd9837fc84fae947a
Reviewed-on: https://gerrit.libreoffice.org/50079
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Ifb434589ef08428ce609bc7a40b015d4df13224c
Reviewed-on: https://gerrit.libreoffice.org/50048
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: If19dbb654d473e8785dc69f96775c78cc95a7bd6
|
|
Change-Id: If986352478f34f54015f1969c97c26e2ef05c06c
Reviewed-on: https://gerrit.libreoffice.org/49444
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ib7ad23257a966447d627b4f73698d9298790f759
Reviewed-on: https://gerrit.libreoffice.org/49042
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Also a few cleanups.
Change-Id: I3269d623917efda3a873f745dbce8bb25dce79be
Reviewed-on: https://gerrit.libreoffice.org/48792
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Fixed some typos and translated a couple of German words
Change-Id: I24ae28dd537ba283a9480413659f85bd6711acad
Reviewed-on: https://gerrit.libreoffice.org/48892
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
... to already open soffice process from newly spawned one on Windows.
When an application takes user input, a timeout is started during
which other processes cannot create foreground windows that might
steal focus, and thus interrupt user input. The timeout is defined
by SPI_SETFOREGROUNDLOCKTIMEOUT (see SystemParametersInfo) and
ForegroundLockTimeout registry setting (see
https://technet.microsoft.com/en-us/library/cc957208). If an
application that currently doesn't have right to become foreground
tries to show popups in this interval, the popup will stay on
background, and only flash in taskbar.
The application that has the right to steal focus (see the list in
https://msdn.microsoft.com/en-us/library/ms632668) may transfer its
right to another process using AllowSetForegroundWindow function.
So, the intended effect is this:
1. User interacts with some foreground process (e.g., Explorer);
a timeout is started to prevent non-privileged processes from
stealing focus;
2. As the result, the process launches a new soffice process, which
has privilege to create foreground windows (as it is started by
foreground process);
3. It communicates with already started soffice process, which is
currently in background, and so doesn't have privilege to create
foreground windows until timeout expires;
4. It transfers its right to the already started soffice process,
and then issues the required commands that might lead to need to
show popup windows.
Change-Id: I4208665c2ae4106fa06e72269f4c3804af40d582
Reviewed-on: https://gerrit.libreoffice.org/48839
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Korr -> Corr in math
Change-Id: I33c3d0fa62aa0c4b6fd418ba2e49b90b019b8714
Reviewed-on: https://gerrit.libreoffice.org/48782
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
|
|
This reverts 5da3337c007e0572028283d70bad43e9a29d45c1 "readded include stdlib.h,
because of missing NULL definition in many headers, #100000, #101685", which is
no longer relevant.
Change-Id: I544ed9a7afbf7b611bc481b8d50acca3193d93de
Reviewed-on: https://gerrit.libreoffice.org/48131
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ieef0e3f21eb12cb5b72d39da4bc0a8c60dd0d5ce
Reviewed-on: https://gerrit.libreoffice.org/48545
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I13acf050d83099be8874514688936bb4ddbb1a26
Reviewed-on: https://gerrit.libreoffice.org/48543
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
...("error: argument to ‘sizeof’ in ‘char* strncpy(char*, const char*, size_t)’
call is the same expression as the source; did you mean to use the size of the
destination?") in a place where the use of strncpy instead of strcpy (introduced
with 9276f7d5740a28b342db2a9bcd8644ff2f4f5742 "fdo#32263") doesn't help prevent
any buffer overflows anyway (the target's size already having been checked to be
sufficiently large).
Change-Id: I70773538f4092f1306fb00f1fa7f9138e06894e5
Reviewed-on: https://gerrit.libreoffice.org/48391
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
based on i#97605's test cases.
Change-Id: Id7e57914553ba8801a624f667979badc191108e5
Reviewed-on: https://gerrit.libreoffice.org/46152
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Eike Rathke <erack@redhat.com>
|
|
Automatic rewrite (of loplugin:cstylecast and loplugin:unnecessaryparen) after
cab0427cadddb3aaf1349c66f2fa13a4234ba4b2 "Enable loplugin:cstylecast for some
more cases" and a409d32e7f6fc09e041079d6dbc3c927497adfed "More
loplugin:cstylecast"
Change-Id: Ib3355159dd08333e1b7a8d091caf2069cdcc7862
Reviewed-on: https://gerrit.libreoffice.org/48317
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ie60f2cc7c3b0bcba7ddf2e7a0f6837c821b33dcc
Reviewed-on: https://gerrit.libreoffice.org/48313
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|