It makes sense to disable a filter, as a temporary security measure,
when there is a 0-day vulnerability in it.
E.g., when 0-day found in AbiWord filter, this config snippet disables it:
<item oor:path="/org.openoffice.TypeDetection.Filter">
<node oor:name="Filters">
<node oor:name="AbiWord">
<prop oor:name="Enabled" oor:finalized="true">
<value>false</value>
</prop>
</node>
</node>
</item>
Change-Id: I8b84250c7e4aac3555877d23f58ed13a2210ebfc
Reviewed-on: https://gerrit.libreoffice.org/50961
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Tested-by: Andras Timar <andras.timar@collabora.com>
auto-rewrite with <https://gerrit.libreoffice.org/#/c/47798/> "Enable
loplugin:cstylecast for some more cases" plus
solenv/clang-format/reformat-formatted-files
Change-Id: I39cc98d11a608d5fdad11c621b4cbde285204095
The only effect SAL_CALL effectively has on LO-internal code is to change non-
static member functions from __thiscall to __cdecl in MSVC (where all other
functions are __cdecl by default, anyway). (For 3rd-party code, it could be
argued that SAL_CALL is useful on function declarations in the URE stable
interface other than non-static member functions, too, in case 3rd-party code
uses a compiler switch to change the default calling convention to something
other than __cdecl. But loplugin:salcall exempts the URE stable interface,
anyway.)
One could argue that SAL_CALL, even if today it effectively only affects non-
static member functions in MSVC, could be extended in the future to affect more
functions on more platforms. However, the current code would already not
support that. For example, 3af500580b
"loplugin:salcall fix functions" changed FrameControl_createInstance in
UnoControls/source/base/registercontrols.cxx to no longer be SAL_CALL, even
though its address (in ctl_component_getFacrory, in the same file) is passed to
cppuhelper::createSingleFactory as an argument of type
cppu::ComponentInstantiation, which is a pointer to SAL_CALL function.
Change-Id: I3acbf7314a3d7868ed70e35bb5c47bc11a0b7ff6
Reviewed-on: https://gerrit.libreoffice.org/46436
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Since there is no XHTML import; and this way the expensive "deep"
detection (that calls into all the DLP libs, etc) can be avoided.
Times for a hello world input: 56 -> 23 ms is spent in
Desktop::loadComponentFromURL() (41% of original).
Change-Id: Ia2dec3837cf0c548ae2c5a0ca4d47a57a6cbb92a
Reviewed-on: https://gerrit.libreoffice.org/46387
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
In this first commit, I use the plugin to verify the consistency of our
SAL_CALL annotations.
The point being to make the next commit more mechanical in nature,
purely using the rewriter.
There are various chunks of unix-only code that have never had to be
compiled by MSVC, hence the inconsistencies.
In bridges, I had to inline some typedefs to make the verification code
happy, since it cannot see into typedefs.
Change-Id: Iec6e274bed857febf7295cfcf5e9f21fe4a34da0
Reviewed-on: https://gerrit.libreoffice.org/45502
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
and exit typedetection early and completely if application quits
while detecting
During typedetection, before loading proper, we have the hidden window as
parent so warnings are not modal to existing windows and they are cancelled on
exit.
Once we do have a window, then reinit interaction handler to have that window
as the parent for any further dialogs.
Change-Id: I5c6711557266bf7d1eb9291f1c454cbfaf766886
Reviewed-on: https://gerrit.libreoffice.org/45148
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
cause that's what its really used for and a couple of cases
are not specifically about avoiding config but avoiding uninteresting
disk acccess and what not
Change-Id: I4c6454f98388579fcd0bf9798321d30408ab65ee
Reviewed-on: https://gerrit.libreoffice.org/44491
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
With all bells and whistles, instead of the crude size/dpi JPG dialog
even for PNG.
Change-Id: I695a78643e07900822ec9253ac818efd52339cc0
Reviewed-on: https://gerrit.libreoffice.org/42498
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>
... and not the crude JPG ones.
The com.sun.star.svtools.SvFilterOptionsDialog service has all we need,
so teach it to cope with non-Graphics source documents and let
ExportDialog handle that as well, just the actual rendering needs to go
via GraphicExportFilter (and effectively DocumentToGraphicRenderer), so
don't let that overwrite the properties set by the filter dialog.
Switching to the dialog then is just a matter of changing the
UIComponent in filter/source/config/fragments/filters/calc_png_Export
The same mechanism probably could be used by Writer as well by adjusting
filter/source/config/fragments/filters/writer_png_Export.xcu and maybe
filter/source/config/fragments/filters/writer_jpg_Export.xcu
in which case the GraphicExportOptionsDialog likely would be moot
then.
Also, it looks like a
filter/source/config/fragments/filters/calc_jpg_Export.xcu
(which doesn't exist yet) could be possible using the same mechanism.
Change-Id: I1fb9b33a6490dc39d7591b2b5913be182bb820e5
Reviewed-on: https://gerrit.libreoffice.org/42421
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>
EPUBExportUIComponent::execute() still needs to launch an actual dialog,
but otherwise it has enough functionality that only tweaking
maFilterData is necessary in the UNO component to pass custom filter
options to the exporter.
Change-Id: I95af024f5babd66a5aa0b446550f4f0fec45ef43
Reviewed-on: https://gerrit.libreoffice.org/42204
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
It doesn't do anything yet, but EPUBExportFilter::filter() is called.
Actual functionality will be provided by libepubgen later.
Change-Id: I7229dc33c69238c6e98a7bb30fd38473b3c35bfe
Reviewed-on: https://gerrit.libreoffice.org/40630
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Seems this is needed in some obscure (internal dialog?) context to enable the
SelectionBox, see sfx2/source/dialog/filedlghelper.cxx
FileDialogHelper_Impl::updateSelectionBox()
Change-Id: If7c7d5ce5362779c25985c7d492878e31c00f283
Reviewed-on: https://gerrit.libreoffice.org/40417
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>
std::binary_function is deprecated since C++11 and removed in C++17
90% done with regexp magic.
removed obsolete <functional> includes.
The std::binary_function base class was used by deprecated
std::bind2nd, this was solved in individual commits.
The members first_argument_type and second_argument_type were used
in chart2/source/controller/dialogs/DataBrowserModel.cxx:
DataBrowserModel::implColumnLess and are inlined in this commit.
Change-Id: I60ded60a8d4afd59e15ac15a58e18d2498c9be5a
Reviewed-on: https://gerrit.libreoffice.org/39659
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
std::unary_function is deprecated since C++11 and removed in C++17
90% done with regexp magic.
removed obsolete <functional> includes.
The std::unary_function base class was used in 3 places:
* chart2/source/tools/DataSeriesHelper.cxx: lcl_MatchesRole
is used in a std::not1 function helper who uses the members
return_type and argument_type.
- replace deprecated std::not1 with a lambda
* chart2/source/tools/ModifyListenerHelper.cxx:
lcl_weakReferenceToSame used the argument_type member in the
operator() parameter.
- inline the parameter type.
* xmloff/source/chart/SchXMLExport.cxx: lcl_SequenceToMapElement
used result_type and argument_type in operator().
- inline the types
Also fix compile error with gcc about finding std::for_each.
Change-Id: I073673beb01410c3108e7d0346d9e7d6b9ad2e2f
Reviewed-on: https://gerrit.libreoffice.org/39358
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
Michael Meeks