...to not need to see the KDriver class from the outer kab wrapper in the inner
kabdrv, and the KConnection class from the inner kabdrv in the outer kab
wrapper, which caused false positives from -fsanitize=vptr.

Change-Id: Ifae4c837ba4da660df0928b50de5114d567e5d9c

The problem is that currentcontextchecker.cxx is linked statically into 2
dynamic libraries, and with clang now using -fvisibility-ms-compat since
commit f0aa1a78 the ASAN complains about
ODR violation in testttols uno_test:

==1818==ERROR: AddressSanitizer: odr-violation (0x2aef08e9c600):
  [1] size=192 'vtable for testtools::bridgetest::CurrentContextChecker'
  testtools/source/bridgetest/currentcontextchecker.cxx
  [2] size=192 'vtable for testtools::bridgetest::CurrentContextChecker'
  testtools/source/bridgetest/currentcontextchecker.cxx

Change-Id: Ie705788dbf035f7a9f64878c6dcf3cec9b7e7ba1

Now Adobe Reader is satisfied with the signature timestamp also for a
PDF signed and timestamped on Windows.

My gleeful commit comment from yesterday about how much simpler the
Win32 crypto API was to use for this task was not entirely true. It is
simpler than using NSS and curl, but not as simple as I had hoped. Oh
well, I am not really surprised.

I now use the "low-level" message functions instead of the single
"simplified" CryptSignMessage(). And just like with NSS, I need to
create the message twice; first to get the signature to timestamp, and
then a second time to attach the timestamp. But now I wonder whether
doing CryptSignMessage() twice would work too. Anyway, won't touch the
code now for a while.

I am actually a bit surprised that the code works... Must have been my
lucky day. Or then I just am good at making educated guesses at what
an API does, even if the documentation doesn't make it perfectly
clear. Especially, I am a bit surprised that calling
CryptMsgGetParam(hMsg, CMSG_BARE_CONTENT_PARAM) returns (just) the
signature. OTOH, what else would it return?

Change-Id: Iec20c7605cf3d841b9e1787184c7b665837f1bc2

Change-Id: I4adad1675f2a880e14ed870a3c74e43e8898c371
Reviewed-on: https://gerrit.libreoffice.org/14663Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>

and forward calls to it from the SvpGraphics

Change-Id: I6d1fbc8919596d5f47661b3471570fcb7e14bc3e

Change-Id: I3d68ec1c7c43773c05344e88cc4eec8edbd4108b

broken since 4bf95c4c "make use of startsWith()"
where the tricky

  !url.compareTo(::rtl::OUString("sdbc:address:kab:"), 16)

was replaced with

  url.startsWith("sdbc:address:kab:")

even though the original exempted the trailing ":" from the comparison

Change-Id: I45175b2669d61eb4cee36d4456ccb69d0f11ef63

broken since LO 3.6, commit 07d512ef
"connectivity: convert kab to gbuild"

Change-Id: I65cc32fa55f1d5c0358585489b8b3dc3aaf8004b

Change-Id: I692a3ce8c917f97bcaa05903c89784c213e6c864

broken with 5d05f7ed "forms: use constructor
feature for form modules" and follow-up misguided clean up

Change-Id: If9447740e6408472722b81d112cd85349020eabe

This is not exactly what the reporter of the issue requested
because this is for "Elements Dock", not for "Elements".
However, according to tdf#68871, Elements Dock would be the
desired place to be improved.

Change-Id: I6806d33f1ea89c7fe7565753f000f7bf747552a5
Reviewed-on: https://gerrit.libreoffice.org/14652Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

Fixed. When I try to paste an web image copied from web browser, it paste now

Change-Id: I696feb3438022b506303b2f354ac9c4d306e08f4
Reviewed-on: https://gerrit.libreoffice.org/14529Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

... specified by the selection attribute.
For its expected behavior, see the section <maction> in MathML 1.01:
<http://www.w3.org/TR/REC-MathML/chap3_6.html#sec3.6.1>

Change-Id: I70c1b2cfe1afec730f3e67ba0938bbaf8ada8e23
Reviewed-on: https://gerrit.libreoffice.org/14600Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

Change-Id: I6519a4c9da2a95efcc54288b3ef9d0a19ccfef3c

Change-Id: Ic7abd7dd588339e06b6764659829f35b4ea87adb

Change-Id: Ib7ed62599b9e088c4a91a39c3181f3a13e641d70

...added in 34504e4a "Chart menu works now" but
never read?

Change-Id: Ie756f831eda6bbb9ac0edb14758e097e30a9be6a

As discussed in b4f6b26b "SAL_DLLPUBLIC_RTTI for
proper RTTI visibility for LLVM," RTTI-based -fsanitize= checks with Clang on
Linux need special precautions to make RTTI symbols visible across DSOs.  The
approach taken there, as well as in 598d8194
"Visible function type RTTI for Clang -fsanitize=function," was to add explicit
SAL_DLLPUBLIC_RTTI annontations to relevant type definitions.  However, for
-fsanitize=vptr that would have required many more of those, so it appears
easier to "misuse" -fsanitize-ms-compat in that case, which happens to give all
RTTI symbols default visibility (while otherwise still honoring our
SAL_DLLPUBLIC/PRIVATE annotations).

The SAL_DLLPUBLIC_RTTI annotations from 598d8194
"Visible function type RTTI for Clang -fsanitize=function" can likely be removed
again.

Change-Id: Ibeff7ab8c908111a7dc66ff0677204f112b24db8

Change-Id: Icf872e269c7e427ba1287ccd0082974c9426449e

Now Adobe Reader is satisfied with the signature timestamp.

I just need to figure out how to do the corresponding fix for the Win32
version, too.

Change-Id: Ie2cce177a9a356e729ca157b4c181e95a2c60c91

Change-Id: Ic9762d9392493a84fe124349e7616ac21f7e8586

Change-Id: Icb57186d823a5fa458b5f6516e04bb06b0a848d9

Change-Id: Ic03fb2ee6470eac6034be13908dd9ec92cf175b6

as it now works again after ancient emf import bug is fixed by

commit 5e5b90c1
Date:   Thu Feb 26 13:47:58 2015 +0000
    in BITFIELDS mode (3) there are *3* pal entries not 12

and two writer qa tests adapted to test for the actual pixel color vs the
underlying pixel data

This reverts commit 3c4f7704.

Change-Id: Id94f98f9c620c90fda097fa97fc34c9ee957c483

Luckily doable with much simpler code than the horrible NSS and curl mess used
on Linux (and, sadly, OS X).

Basically only one new API call needed: CryptRetrieveTimestamp(). A few hours
of work, compared to about a week for the Linux case.

However, amusingly, it causes the same message in Adobe Reader as when using
the NSS code: "The signature includes an embedded timestamp but it could not
be verified". Sigh.

Change-Id: I98c973bd50b841d1ae3feb8a695bac29da538b6c

Change-Id: Ic82f64746e657c44f8a16e78dedc6e85aa95544b

Change-Id: I957bf1d5bd88b15539e95dfa4aa87a8e63a96439

Change-Id: Ia8e18db1870dbecc7b2edb2f4908ada806ff2a95

Change-Id: I369564f23d20d5b4bb890eed41ad48842615ee44
Reviewed-on: https://gerrit.libreoffice.org/14634Tested-by: Jenkins <ci@libreoffice.org>
Tested-by: Michael Stahl <mstahl@redhat.com>
Reviewed-by: Michael Stahl <mstahl@redhat.com>

Change-Id: I86bdd1c2603c984380b52b080504b7583155b0fb

Change-Id: Id6f835a9eb8d679b293114a887a81dbf47260bbf

Change-Id: I5b41039bf63a4c2f313fe7a57c0f6934dcb0752d

Based on profiling, Writer's most CPU consuming idle event was
document statistics calculation.
This patch stops the idle timer once statistics has been updated.
Subsequent profiling shows a sharp decline in CPU usage.

Modifications to the document should initiate statistics update.

Change-Id: I8c38ad8847987264549945e4f482ea18d2635283
Reviewed-on: https://gerrit.libreoffice.org/14575Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>

Needs also 0cd15b44 if edges are to be
expanded and formula grouping is affected.

Change-Id: Ib3cee8dd214d216907248316a2ac5a290399b169

Edge expansion may change expressions individually, which must be split
off the group.

Change-Id: Id4328bd8c42f2ff9f83d2edc845537971f3a39d3

Change-Id: I44f1bbc9798312cea93c2cd7fadb0c3b7f26a9b7
Reviewed-on: https://gerrit.libreoffice.org/14640Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>

Change-Id: Id4c43a6bcdf915b98410af9ceb0dbf20df3a9498

Change-Id: Iee0fcb8e2b91a6554bedc7e3989c0585a1679a61

Change-Id: I2dbab9e972c7470e9bd30692e54c51ee11ffd45b

Change-Id: Ifb18d5fd0b330dde0edc428621af417ddc836b21