Age | Commit message (Collapse) | Author | Files | Lines |
|
Where option "-R" means, according to the open(1) man page: "Reveals the file(s)
in the Finder instead of opening them." This appears to always reveal in
Finder, even for *.app "application directories", so should not affect
CVE-2019-9847.)
Change-Id: I775db7bf71c09adc6570931a977b82dfee8dc95a
Reviewed-on: https://gerrit.libreoffice.org/82749
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
(cherry picked from commit 1ff1466b055890b2ca0ff3a47262bc048ad78542)
Reviewed-on: https://gerrit.libreoffice.org/82757
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
Thanks to the Paul's (paul@claws-mail.org) contribution
Change-Id: Ie4144ab78691b33d8d341d4520c40c56010a0dd8
Reviewed-on: https://gerrit.libreoffice.org/79423
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
(cherry picked from commit 1c03df6e82e4bf30294fc0b9e64de5cc39efc5c4)
Reviewed-on: https://gerrit.libreoffice.org/79460
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
|
|
This only fixes part that the URL refuses to open the target file.
Honoring fragment isn't fixed here, since it's the system call to
ShellExecuteExW that in this case internally converts the file URL
into a system path, and strips the fragment from it.
Regression from commit d59ec4cd1660410fa1b18c50d2d83b1417a82ddc.
Change-Id: I6c9ed27e9a5bd7f2780dd3be96f816a6e825e043
Reviewed-on: https://gerrit.libreoffice.org/76778
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
(cherry picked from commit 2207269a84c7c9920af3385b837ce67978c720b4)
Reviewed-on: https://gerrit.libreoffice.org/76848
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
There is already a large comment in initAttachmentList about
problems with MAPI_DIALOG_MODELESS. Using MAPI_DIALOG_MODELESS with
Outlook 2016 and multiple attachments sometimes produces a
MAPI_E_FAILURE, but most times it crashes for me. And it's not a
problem with the removed temporary files, as uncommenting that
shows the same problem. And there seems to be many more problems:
https://social.msdn.microsoft.com/Forums/en-US/5d8fece6-9d93-490c-9331-625c17e3291d/mapisendmailhelper-and-mapidialogmodeless
But actually I don't see any blocking of LO, if I switch to
using MAPI_DIALOG, as senddoc.exe already runs in the background.
So this switches MAPI_DIALOG_MODELESS to MAPI_DIALOG.
This reverts commit 5874c76371562c3e2d8564b1fb04df1997091d27
("tdf#116074: Use modeless dialogs with supporting mailers").
Change-Id: Ie0f8f22196d1a174dfeada2bc4aabb1717ee16a7
Reviewed-on: https://gerrit.libreoffice.org/76155
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
(cherry picked from commit e79f61340405dcc75f3fe41f727dea4ba4202c2e)
Reviewed-on: https://gerrit.libreoffice.org/76610
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
|
|
... in preparation for further changes.
Thanks to Noel Grandin for the hint!
Change-Id: I2b223322d1d42099b56a74a92e3c39631d6b581c
Reviewed-on: https://gerrit.libreoffice.org/72470
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
ViewDocument3 method takes OpenType parameter, which allows to decide
if user can choose opening the document read-only or to edit.
Since we need to show localizable strings, we need to bootstrap part
of LO (l10n), which is impossible when e.g. 64-bit ActiveX DLL tries
to load installed 32-bit sal DLLs. Thus, we need a separate helper
.exe, which architecture matches the rest of installed LO, and which
handles user interaction.
Change-Id: I0ad53ba64272fb84728d2221e3dc85d3eefdda68
Reviewed-on: https://gerrit.libreoffice.org/72355
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Ib7ed7b3d94c04c09debe910a76cd720802f1a6f6
Reviewed-on: https://gerrit.libreoffice.org/72475
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I60f7bbb2921b242396b4620077ca30e12a0d3b4b
Reviewed-on: https://gerrit.libreoffice.org/72393
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Also simplify it, don't issue warnings for now, until we understand
clearly what each its option implies.
Change-Id: I0d74a42b878991ad84c5c3bba36c8978d920b9be
Reviewed-on: https://gerrit.libreoffice.org/72337
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Idf5e77e4122ad4b5b91f25c50fdaaf25e34a76ae
Reviewed-on: https://gerrit.libreoffice.org/72336
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Ib03bfd795967ba70333d71d9e5eeec97be90be79
Reviewed-on: https://gerrit.libreoffice.org/72334
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Who was that idiot who initially used wrong values??? Hmm... oh damn,
that was me :-(
Change-Id: I3bfde7511bcf8adfa38ae68372f21511f21efca1
Reviewed-on: https://gerrit.libreoffice.org/72308
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
This prevents SharePoint from trying to download documents in browser
after they were already opened by LibreOffice SharePoint integration
ActiveX control.
The implementation just returns true, to avoid instant refresh of the
site in browser. TODO: fine-tune when understood when and why it makes
sense to return false.
Change-Id: I1ceae82db16ca8e418850fafd8c171ee6a2e039b
Reviewed-on: https://gerrit.libreoffice.org/72266
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Similar to clang-tidy readability-container-size-empty
Change-Id: Icabd773f3b924d465b33e8581175f1fcf70c282e
Reviewed-on: https://gerrit.libreoffice.org/71704
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Two use-cases here in kde5backend
1) kde or qt vclplug has already started qt event loop => just use this
loop to read KDE settings
2) no qt event loop runs (we're most likely in gtk3_kde5 vclplug) =>
start a new event loop, read the settings and stop it
In case 2) letting qt event loop run means subsequently all UI ops
need to happen in main thread. This is problematic to enforce in
non-qt-based vclplugs
In both cases, cache those settings for future use - the assumption is,
most of them are static during a session anyway.
Change-Id: Ifa203f4cdb9a753db808f945762fb131ee83393c
Reviewed-on: https://gerrit.libreoffice.org/70808
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
this copy'n'pasta blunder looks innocuous but can slow down loading
of JVM (which reads proxy settings among others) in KDE environment
significantly
Change-Id: I98f0fb107a2ee825bcd47731a5a9d15017ba63bc
Reviewed-on: https://gerrit.libreoffice.org/70806
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
... of user templates
This is kludgy yet better than making innocent users waiting for
the template dialog ~forever as pointed out in the comments in
<https://gerrit.libreoffice.org/#/c/67741/>.
Change-Id: I6dfdc0408effb06cc9175cd976ea6687e52a7136
Reviewed-on: https://gerrit.libreoffice.org/69883
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I7d85cbc9105c5e0c4a8d9a69c4ac9d6dfc07eabd
Reviewed-on: https://gerrit.libreoffice.org/70663
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
The code is using expicit (mostly W) Windows API, and is independent
from the macro. Removing it here allows to catch places where some
UNICODE-dependent macro is used unintentionally.
Change-Id: I5dff40aecfc3c3dc7fc4cf7271a995a675943a45
Reviewed-on: https://gerrit.libreoffice.org/70237
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I21b4df5b595c3814a5a3fb85d9da531729447b7e
Reviewed-on: https://gerrit.libreoffice.org/70193
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I87fd37e56326bef4888354b923407530c6f70760
Reviewed-on: https://gerrit.libreoffice.org/70177
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I07604028845c49cc084927e21db7f21c5d053bab
Reviewed-on: https://gerrit.libreoffice.org/69796
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ie91f0bf21e6f5c3f7a7aa4ae3d1dff6cc8e15a86
Reviewed-on: https://gerrit.libreoffice.org/69597
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I1576282b0a0a3af8ae14c04725d9c4900073f2c4
Reviewed-on: https://gerrit.libreoffice.org/68758
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I94689e4eed290b4505d2caba2d9802ef7fb6cffd
Reviewed-on: https://gerrit.libreoffice.org/68378
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
... for My Documents and My Templates.
It seems customary to name XDG_*_DIR in all uppercase. This also
fixes buffer overrun IIUC, as osl_readLine() does not return the
newline delimiter.
Change-Id: If85ca7e6abe663e29d36b65a08d358d3d7d27c4b
Reviewed-on: https://gerrit.libreoffice.org/67741
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I3bd23a8f6237d0887a4782b6179a413dd2f03e02
Reviewed-on: https://gerrit.libreoffice.org/67564
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Id58f692168274a942d2b976f10885341dfe63ac3
Reviewed-on: https://gerrit.libreoffice.org/67434
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This fixes and extends dad7c2213979695cf3573a130309206191b45157 .
Change-Id: I29352d4b4809aa254e832a932bfeb595d065565b
Reviewed-on: https://gerrit.libreoffice.org/67368
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: I0cd14e0ace9c9d2fcd880477b0485295e3010b71
Reviewed-on: https://gerrit.libreoffice.org/67138
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ib6320ddc049e93cca4c5931ad28d1873d34bd8b4
Reviewed-on: https://gerrit.libreoffice.org/67137
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Since it is now possible to use C++14, it's time to replace
the temporary solution with the standard one
Change-Id: I6eea0877eaa1886b64c0cce06a43b8088cbccd8e
Reviewed-on: https://gerrit.libreoffice.org/66751
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: Ic307226591ff9702957ccdec486ccf70357eb6d9
Reviewed-on: https://gerrit.libreoffice.org/65951
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
KDE4 is out of maintenance upstream since Nov. 2014, and binaries
provided by TDF have switched to KDE5 as the official backend.
Change-Id: I165465b56d3ba3a18912b203c06ae8fc6111c0c9
Reviewed-on: https://gerrit.libreoffice.org/60014
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
Use range-based loop or replace with STL functions
Change-Id: I42361d6a73d201db8eb6dca09d79768e2d62051d
Reviewed-on: https://gerrit.libreoffice.org/64389
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I651b7f202fa52ff5f5357a11aa72c43eb7dc7f95
Reviewed-on: https://gerrit.libreoffice.org/64102
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
Change-Id: I6d51e4eb4a49a30193b904b2c7d62df1e16ea3d9
Reviewed-on: https://gerrit.libreoffice.org/63475
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I8217b1a0b6ccc29052257d54ba7844c0970ad9a4
Reviewed-on: https://gerrit.libreoffice.org/62859
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
V547 Expression 'procHandle != nullptr' is always false.
The code was nonsensical overall. First, the launched process handle
was never returned by ShellExecuteExW, because SEE_MASK_NOCLOSEPROCESS
wasn't used, so GetProcessId couldn't succeed. Then, nullptr window
handle was passed to GetWindowThreadProcessId, thus never returning a
meaningful result.
This reimplements this to find the launched process' main window by
first waiting for process idle (up to 1-second delay is possible),
then enumerating all the top-level windows and checking their process.
Change-Id: I5fb4c04147b3f9414e27650a023f7844523c18bd
Reviewed-on: https://gerrit.libreoffice.org/62478
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I444c43b9d549977039f25bec2b5bf666c3e15e0e
Reviewed-on: https://gerrit.libreoffice.org/62041
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
which seem to have snuck back in since the great rounds of removals.
Change-Id: I85f7f5f4801c0b48dae8b50f51f83595b286d6a1
Reviewed-on: https://gerrit.libreoffice.org/62229
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ia443a0e61a091d877c8da26bf7d45bf4261f8669
Reviewed-on: https://gerrit.libreoffice.org/62166
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ida6250fc01e0bf156a81030c2f393838ced423fe
Reviewed-on: https://gerrit.libreoffice.org/61998
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
...where "inline" (in its meaning of "this function can be defined in multiple
translation units") thus doesn't make much sense. (As discussed in
compilerplugins/clang/redundantinline.cxx, exempt such "static inline" functions
in include files for now.)
All the rewriting has been done automatically by the plugin, except for one
instance in sw/source/ui/frmdlg/column.cxx that used to involve an #if), plus
some subsequent solenv/clang-format/reformat-formatted-files.
Change-Id: Ib8b996b651aeafc03bbdc8890faa05ed50517224
Reviewed-on: https://gerrit.libreoffice.org/61573
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ib30c45bddcc58fcd0fec8b160eb925349e801df7
Reviewed-on: https://gerrit.libreoffice.org/61551
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Iee1be29bb4f6a90ccc38d2da8372046350ada438
Reviewed-on: https://gerrit.libreoffice.org/61111
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Id6f7bf29ff957455bfb2e1687a285a45529b77a0
Reviewed-on: https://gerrit.libreoffice.org/60966
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Including:
* expanding STDAPI to its definition (as per
<https://msdn.microsoft.com/library/ms686631(vs.85).aspx> "STDAPI"), to add
__declspec(dllexport) into its middle, in
extensions/source/activex/so_activex.cxx; as discussed in the comments at
<https://gerrit.libreoffice.org/#/c/60691/> "Get rid of Windows .def files in
setup_native, use __declspec(dllexport)", having a function both listed in a
.def file EXPORTS and marking it dllexport is OK, and the latter helps the
heuristics of loplugin:external; however, the relevant functions in
extensions/source/activex/so_activex.cxx probably don't even need to be
exported in the first place?
* follow-up loplugin:salcall in sal/osl/w32/file-impl.hxx
Change-Id: Ida6e17eba19cfa3d7e5c72dda57409005c0a0191
Reviewed-on: https://gerrit.libreoffice.org/60938
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Since we can't load Qt4 and Qt5 based libraries in one process
prevent loading the conflicting config backends based on the VCL
backend.
Also removes the reference to the long gone KDE3 backend.
Change-Id: I7a9bc449ebf825b47882f8bd207496a2a9597608
Reviewed-on: https://gerrit.libreoffice.org/60764
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Change-Id: Ib06572a844d2999e9ecd91e26abd98ecec06a0ae
Reviewed-on: https://gerrit.libreoffice.org/60665
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|