Change-Id: Ic8e7a7c0f6f40521dfb20ebf4ef11f2776c0cde8

Change-Id: I254c7a4b6f822c71b3ad5150cf674d25defbf1ed

When destroying the static vcl::CommandInfoProvider aProvider from
vcl::CommandInfoProvider::Instance (vcl/source/helper/commandinfoprovider.cxx)
during exit, it releases its mxCachedGlobalAcceleratorConfiguration reference on
GlobalAcceleratorConfiguration
(framework/source/accelerators/globalacceleratorconfiguration.cxx), which may
get destroyed, whose base class framework::XCUBasedAcceleratorConfiguration
(framework/source/inc/accelerators/acceleratorconfiguration.hxx) has a
salhelper::SingletonRef<framework::KeyMapping> member, whose destructor
(include/salhelper/singletonref.hxx) uses
salhelper::SingletonRef<framework::KeyMapping>::SingletonLockInit::operator ()'s
static osl::Mutex aInstance.

If, during construction, the instantiation of
salhelper::SingletonRef<framework::KeyMapping>::SingletonLockInit::operator ()'s
static osl::Mutex aInstance finishes before the instantiation of
vcl::CommandInfoProvider::Instance's static vcl::CommandInfoProvider aProvider,
the corresponding atexit cleanup actions will be recorded in the right order,
causing the above chain of calls to find the static Mutex still alive when used
from within the static CommandInfoProvider's destruction.

However, vcl::CommandInfoProvider's mxCachedGlobalAcceleratorConfiguration is
only set to css::ui::GlobalAcceleratorConfiguration::create in
vcl::CommandInfoProvider::GetGlobalAcceleratorConfiguration, so the
instantiation of the static Mutex instance can finish after the instantiation of
the static CommandInfoProvider instance, recording the atexit cleanup actions in
the wrong order, causing the static Mutex to be used after destruction.

This occasionally caused PythonTest_sfx2_python to hang during exit for me on
Linux, where trying to lock a destroyed pthread mutex can apparently deadlock.

rtl::Static does away with the need to do anything in the destructor, at the
expense of always keeping the instance alive until exit (and not being able to
recreate an already destroyed instance during exit, but code that would require
that behavior would probably already be broken to begin with), so the order of
creation of the CommandInfoProvider and GlobalAcceleratorConfiguration instances
becomes less of a concern.

Change-Id: Id6e3860ad9e5b7045980a0b9bf9eaef2e24129bb

from another application, e.g. text from gedit or a standalone
image (view image) from firefox

Change-Id: I68b82217eb2513cedc096f5ff653fb7c75b48052

With this, the xmlSecTransformIdListFindByHref() call in
xmlSecTransformNodeRead() recognizes the
http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 string as a valid
signature method as well. Previously SHA-256 was recognized as a digest
method only.

Change-Id: Ib20ab97dd5bc86dff761f0c58a87afdde112e1e8

Regression from commit f4badd9a
(tdf#92454 DOCX import: allow overriding para prop from num style in
para style, 2015-09-22), the problem was yet another priority
mishandling in the maze of various styles and indentation handling.

In the tdf#92454 bugdoc, both a numbering-from-paragraph-style and a
paragraph-style defined indentation, and Word preferred the numbering,
while Writer preferred the paragraph style, that's why the import-time
conversion was added.

However, it turns out there is a 3rd source that's still not direct
indentation formatting: a direct numbering. So the correct priority is:

direct-ind > ind-from-num > ind-from-parastyle > ind-from-num-from-parastyle

Which means in this case the indentation should not be set directly: the
two conflicting value (ind-from-num and ind-from-parastyle) will be
resolved correctly by Writer core.

Given that we always first get the para style info, and only then the
numbering, we just need to undo the conversion added for the other bug
if we see a direct numbering, then both the old bugdoc and this new one
will be handled properly.

Change-Id: I09cc84605d5df6159da985ad069d46b580a53358

Project: help  184121fb7abffe19012e3a64187281f0332a4b20

lists cannot be nested directly - use hackaround using switch instead

Change-Id: I9a39112dbaca103ddb6b2783b5a142b280fbba8b

<vcl/openglwin.hxx> is a more light-weight include file and including
that causes less trouble on the various platforms.

Change-Id: I5c9baa171278d291468ef45a47d9fdbc64326957

Change-Id: Iff29ac615ad4b6516790b1cbbde0215a3cd0efe6

... there's no parent style set

Sample:
<?xml version="1.0" encoding="UTF-8"?>
<svg height="600" width="400"
xmlns="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink"
font-size="100%">
<text x="5" y="15">Sample 1</text>
</svg>

Change-Id: Iec88c148475bf8a610286414083e9801faaf8d78
Reviewed-on: https://gerrit.libreoffice.org/21553Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Armin Le Grand <Armin.Le.Grand@cib.de>

Change-Id: I592b8f678288c1229e66abb98f6bb5f865f177a0

Change-Id: I4c80f7055ccb9979bfb89cf9139561287d9659a4

Change-Id: Ia91b3837ce39ae48e8c660274a08415ee4f9e5c7

Change-Id: I15a4237a1ab6d7c180b52c3f8d2834c0e034b7db

after commit c43fdd74
"vcl: GF_VERT is *only* for Windows implementations"

Change-Id: I8f500c0e9accc781a57ab4057eea9d077f418696

This is a 'local' test, meaning it can be done without a
WebDAV server.

It's the first one, so very trivial...

Change-Id: Idf660c7482c86251be02536106f079ac6bdef4b4
Reviewed-on: https://gerrit.libreoffice.org/21658Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>

Change-Id: I4f0a6264a6c6c2533a32de358216601495c959f2

Change-Id: I547a0028a24c6a32e2b13acb9a6b077da8b56964

Change-Id: I1b329a8242800b9b33b891b1fb9b5810be6397e5

Change-Id: I5c5d1652330e9a76d46e596fc49ac732327c6484

Project: help  6eb5558b50b74b2ad51f05b8273c7e1bd72ba8f3

missing id attribute on table

Change-Id: I0be7339ef7b905499bd58877e1278d052b6b5131

The DBG_ASSERT followed by the same test actually returning immediately
prevents the actual 'search' after a 'search all' being performed.

I hope this does not have any negative consequences; but if it does, we should
fix the root cause, instead of having this kind of defensive programming here.

Change-Id: I909533f301dda9c20cab1968de45e5fa7975e852

Project: help  bb4361c2e733c7b5a6a3a4b9d37ec0586c99ccd7

link is no valid child of emph

Change-Id: I24009c8eb766d2e99ff96b8ba803e0d92ee73387

This is still a skeleton, but now we canonize the incoming data, not just
eat it and output nothing -> at the end we don't hit an assertion that
the output of the transform chain is nothing.

Change-Id: I28509b8a493c6bf6cdcbb23b95ae7de8947790c1

With this, if see an URI like:

/_rels/.rels?ContentType=application/vnd.openxmlformats-package.relationships+xml

Then it is properly detected that it's the .rels stream of the _rels
storage, and UriBindingHelper will serve that stream (when looked up by
name later) to libxmlsec.

Change-Id: Iac62cb170c0aa8bb92c40311fb7b248e96c25dde

This reverts commit 5398664e.

 Conflicts:
	include/sfx2/sfxcommands.h
	sw/source/ui/app/mn.src

Change-Id: Ic55cfb51a726ab9ee19bac6719d5e2670d1fb494

Change-Id: Iefa9cad66248297e4639567cd3f5836abb2e167c

Change-Id: I60fafe283740f6246fa2978a1d2e4ee283ecea87

Change-Id: I17a2bf413d5152765821585fabf2123a08b729ca

Change-Id: I8714718830f8b86567ef2750373ce2dab828c07f

Change-Id: I19d8ea633d5fd5462af29a43b916518a31a94787

Change-Id: Id30e109a8292f92e5b384c1262dea0c09d255058

after my OInterfaceContainerHelper2 change

Change-Id: Id63fd81643b030e0570f00d6e0506cb8ea5d3742

Change-Id: I4a49ef84b95e90976a8c1ed76a628c1d0dbf4ed2

Change-Id: I28579cb30397ac88c94952632e7cd3db7277dce0

Change-Id: I936e1aae42da7a065406d7e094e1847d54805f86

after my OInterfaceContainer2 change

Change-Id: I4adb4a1937c12c1f6cb9183d567afb729d4e78ea

Change-Id: I8a77b199562ebffba94c4985693280db91cb0575

Change-Id: I019956e80c310317314673c6444e38e6e78ec7f2

Change-Id: I201f8e5281332ae9668f59060ea2a94f211a7c68