Since there is also no other information, like a label. Also
removes one unneeded level of layout indirection.

I'm not sure about the root placeholder child added by glade, but
other dialogs have it too, so keep it.

Change-Id: I235cc1ab5ea9ef37079353ee150eb000cb665dd1
Reviewed-on: https://gerrit.libreoffice.org/73075
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>

Change-Id: If62dcbffe6514966418bbf78ef3392cc3219f159
Reviewed-on: https://gerrit.libreoffice.org/73074
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>

(regression from c6b7f555)

This reverts commit c5338e3a.

The actual problem was fixed in previous commit for tdf#125475.

ValidateFrame() must only be called in text formatting with a
SwTextLineAccess keeping the corresponding SwTextLine alive.

Change-Id: I5b092b094f620f2dc2524aa5a83c673ec6b1fbbe
Reviewed-on: https://gerrit.libreoffice.org/73048
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>

SwCache::DeleteObj() may decide to shrink the cache, and then the
SwTextFrame::mnCacheIndex goes stale, because only
SwCacheObj::m_nCachePos is updated.

In this bugdoc, this can happen *inside* SwTextFrame::Format(), where
first it succeeds to find an existing SwTextLine, then some footnotes
anchored in this paragraph are moved around and formatted, creating new
SwTextLines, and SwCache::DeleteObj is called.  Later, any access of the
original frame's SwTextLine fails to find it and eventually some null
pointer crash happens.

Newly added SwTextLine::UpdateCachePos() requires that SwTextFrame lives
longer than its SwTextLine; there was another problem with that, because
SwTextFrame::FormatEmpty() was throwing away the mnCacheIndex, which
could then cause a second SwTextLine to be created for the same
SwTextFrame, and the first one is not deleted until it falls to the
bottom of the LRU list.

Apprently for this particular document the problem didn't happen before
commit 3d37463e and/or
commit 31ae7509 but that is mostly luck.

Change-Id: I7bef1b340a453d6dd44d51a1dc69ee5fd0b697db
Reviewed-on: https://gerrit.libreoffice.org/73047
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>

up to maximal size of primFontSz constraint.
Do not override text size changed by user.

Change-Id: If7ea6bbb96cb839831d877edc274a1b0eefdaf21
Reviewed-on: https://gerrit.libreoffice.org/73050
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>

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

ZipPackageStream::saveChild() already had one threaded compression,
but that still uses only one thread for one stream. Many documents
contain many streams (where this is useful), but large documents
often contain one huge content.xml, which then would be compressed
using just one thread.
But it is in fact possible to do deflate in parallel on the same data,
at the cost of somewhat increased CPU usage (spread over threads).
This is handled separately from the background thread path, as
integrating these two approaches would probably be needlessly complex
(since they both internally use ThreadPool, the tasks should often
intermix and parallelize anyway).
On my 4-core (8 HT threads) machine this reduces the compression time
of tdf#113042 from 3s to 1s.

Change-Id: Ifbc889a27966f97eb1ce2ce01c5fb0b151a1bdf8
Reviewed-on: https://gerrit.libreoffice.org/73032
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>

It can be easily separated out, it looked like hacked in. And
I will need to do more refactoring of the class, so this shouldn't
be more complex than necessary.

Change-Id: I302da55409e9195274907ca4939c37fbb2427b18
Reviewed-on: https://gerrit.libreoffice.org/73031
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>

E.g. with the bugdoc from tdf#93553, most of the streams to save
are actually small, they just do not provide XSeekable. Since it
seems all the streams are already fully available by the time
the zip packaging is done, fallback to XInputStream::available()
to find out if the stream is small.
With this, the zipping part of saving tdf#93553 is now down
from ~1.5s to ~0.5s.
This presumably also makes the hack for tdf#93553 unnecessary.

Change-Id: Id9bb7d835400d6d8f147f5c11ade684a549aba53
Reviewed-on: https://gerrit.libreoffice.org/73030
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>

Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.

Change-Id: I202a98d76a37a564315374893b44ec25ef7798b3
Reviewed-on: https://gerrit.libreoffice.org/73005
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>

Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.

Change-Id: Ic331c845f0a8f06c4a8f8f79b6f87e26ca7c3a7d
Reviewed-on: https://gerrit.libreoffice.org/72972
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>

Based on the corresponding macOS code. Work in progress. The image
support ifdeffed out still (because it uses some macOS specific APIs
for which I couldn't right away find the equivalent iOS ones).

I made it much simpler than the macOS code. I dropped the keeping of a
local in-process clipboard completely. Firstly, as far as I see, the
iOS clipboard API (UIPasteboard etc) does not even offer the
possibility to separately offer some formats and actually provide the
data on request. Secondly, we must be prepared anyway that the system
can kill an iOS app at any stage while the user is using some other
app, so we need to make sure everything that is copied goes onto the
system clipboard right away anyway.

I had to disable the copying of HTML to the clipboard as that lead to
a mysterious assertion failure. See comment in
DataFlavorMapper::openOfficeToSystemFlavor(). But RTF seems to work
well, too. I assume RTF is what gets used for cross-application
copy/paste (and cross-device, even, through Apple's Universal
Clipboard thing, where you can copy/paste between your Macs and iOS
devices on the same network).

I am not sure how relevant the various application/x-openoffice-foo
formats are.

Change-Id: I174495e33d86fc3990996c229243c05d6cbfcda7

Change-Id: I816ccde944903e0ff3ac23e92632056a3192b060
Reviewed-on: https://gerrit.libreoffice.org/73069
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>

When pasting a table we get:

warn:legacy.osl:29407:29407:sw/source/core/layout/findfrm.cxx:1136: <SwFrame::FindPrevCnt_()> - unknown layout situation: current frame should be in page header or page foote

... because SwCellFrame's constructor inserts the content of the cell
before the SwCellFrame's mpUpper is set, so it's not connected to
anything; hence FindNextCnt()/FindPrevCnt() can only return frames
inside the cell anyway, and all of those are newly created, so
invalidating a11y flow-relations for them seems pointless because a11y
doesn't even know about them yet.

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

See http://document-foundation-mail-archive.969070.n3.nabble.com/Fishy-assignment-in-editdoc-editeng-td4262109.html

Remove the previous comment less clear

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

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

Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.

Change-Id: Ie2d1a6dad1dc17777f05aa033ea5fed1807261ce
Reviewed-on: https://gerrit.libreoffice.org/72636
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>

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

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

Change-Id: Id12838cf08a2e5b74b53bd0036804b886b41098f
Reviewed-on: https://gerrit.libreoffice.org/73041
Tested-by: Jenkins
Reviewed-by: Gülşah Köse <gulsah.kose@collabora.com>

Change-Id: I521b3a86d1fb215c6f355b198cfd5d9b5f777490
Reviewed-on: https://gerrit.libreoffice.org/73040
Tested-by: Jenkins
Reviewed-by: Gülşah Köse <gulsah.kose@collabora.com>

Change-Id: I6c09bf2af4b902fdc215ec31bf2dad490e41384e
Reviewed-on: https://gerrit.libreoffice.org/73066
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>

Metafiles may have an external header, so once graphic data is read, we
need to set the size explicitly. Otherwise the width of the EMF image in
the bugdoc will be too small.

Change-Id: I2441eda61278b0f4973db5d9aa14618ccd17c397
Reviewed-on: https://gerrit.libreoffice.org/73064
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>

Fix for tdf#115434 prevents key presses being passed through to document
window from the sidebar docking window. This patch only prevents left,
right, down, up, page down/up, home, end, backspace, delete, insert and
return keys from being passed.

Change-Id: I97ab60a214cb9910f526a475f3134784728b7d9a
Reviewed-on: https://gerrit.libreoffice.org/73073
Tested-by: Jenkins
Reviewed-by: Jim Raykowski <raykowj@gmail.com>

FinalizeImport() could be triggered by accident while
editing the document. Now we set it by checking
PROP_REDLINE_REVERT_PROPERTIES used only in OOXML import.

This is a clean-up of the commit 8acc15b5
"tdf#118699 DOCX import: don't add numbering."

Change-Id: Ib1f4ee41ba94d640788396037b668b85b800f9d0
Reviewed-on: https://gerrit.libreoffice.org/73043
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>

This uses the same background color then the edit entries and
changes the focus from the gray filled rectangle to a non-filled
rectangle using the general highlight color.

Change-Id: I4b44811e768266ccd2081a8e3ef61483a803da3b
Reviewed-on: https://gerrit.libreoffice.org/72795Reviewed-by: Heiko Tietze <tietze.heiko@gmail.com>
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>

Change-Id: I67550b325a0ac177ffbd52718234c2a0edf1154c
Reviewed-on: https://gerrit.libreoffice.org/73033
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>

Change-Id: I6f432d773c71eea34693a74bd8ee44562ade1702
Reviewed-on: https://gerrit.libreoffice.org/73063
Tested-by: Jenkins
Reviewed-by: Andras Timar <andras.timar@collabora.com>

Change-Id: If7595983f7bf2d990687a64659a63a8a66b120bd
Reviewed-on: https://gerrit.libreoffice.org/73049
Tested-by: Jenkins
Reviewed-by: Andras Timar <andras.timar@collabora.com>

Those should mean an error somewhere, e.g. as in the recent libcmis fix.

Change-Id: Iecb973a8f1d56a1bfa0a0e8a5c923e5598682b94
Reviewed-on: https://gerrit.libreoffice.org/73029Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
Tested-by: Jenkins

Broke the build on Ubuntu 18.04:

In file included from /home/tinderbox/core-master/workdir/UnoApiHeadersTarget/udkapi/normal/com/sun/star/uno/XInterface.hpp:10:0,
                 from /home/tinderbox/core-master/workdir/UnoApiHeadersTarget/udkapi/normal/com/sun/star/uno/Exception.hpp:8,
                 from /home/tinderbox/core-master/workdir/UnoApiHeadersTarget/udkapi/normal/com/sun/star/uno/RuntimeException.hpp:8,
                 from /home/tinderbox/core-master/include/com/sun/star/uno/Any.hxx:37,
                 from /home/tinderbox/core-master/include/com/sun/star/uno/genfunc.hxx:27,
                 from /home/tinderbox/core-master/include/com/sun/star/uno/Sequence.hxx:35,
                 from /home/tinderbox/core-master/include/svl/sigstruct.hxx:27,
                 from /home/tinderbox/core-master/xmlsecurity/inc/xsecctl.hxx:23,
                 from /home/tinderbox/core-master/xmlsecurity/source/helper/xsecctl.cxx:22:
/home/tinderbox/core-master/include/com/sun/star/uno/Reference.hxx: In instantiation of ‘static com::sun::star::uno::XInterface* com::sun::star::uno::Reference< <template-parameter-1-1> >::iquery(com::sun::star::uno::XInterface*) [with interface_type = com::sun::star::xml::crypto::XXMLSignature]’:
/home/tinderbox/core-master/include/com/sun/star/uno/Reference.hxx:279:42:   required from ‘bool com::sun::star::uno::Reference< <template-parameter-1-1> >::set(const com::sun::star::uno::BaseReference&, com::sun::star::uno::UnoReference_Query) [with interface_type = com::sun::star::xml::crypto::XXMLSignature]’
/home/tinderbox/core-master/xmlsecurity/source/helper/xsecctl.cxx:190:124:   required from here
/home/tinderbox/core-master/include/com/sun/star/uno/Reference.hxx:70:73: error: incomplete type ‘com::sun::star::xml::crypto::XXMLSignature’ used in nested name specifier
     return BaseReference::iquery(pInterface, interface_type::static_type());
                                              ~~~~~~~~~~~~~~~~~~~~~~~~~~~^~
/home/tinderbox/core-master/solenv/gbuild/LinkTarget.mk:290: recipe for target '/home/tinderbox/core-master/workdir/CxxObject/xmlsecurity/source/helper/xsecctl.o' failed
make[1]: *** [/home/tinderbox/core-master/workdir/CxxObject/xmlsecurity/source/helper/xsecctl.o] Error 1

Change-Id: I864da5bd6d163a3de35280bff367e6b51aced23d
Reviewed-on: https://gerrit.libreoffice.org/73035Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins

A chart in a footnote was appeared in every footnotes,
resulting fatal problems during a few import/export cycles,
see tdf#115558 (MSO is unable to open the DOCX export
with multiplied objects).

Change-Id: Ib729e4442ed3c92e4646fa7cdf7253a963d883e8
Reviewed-on: https://gerrit.libreoffice.org/73025
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>

In preparation of forward-porting the distro/collabora/cp-6.0-only
commit 418adc09 (lo: disable under-used
hyperlink fields that are buggy online., 2019-05-22), which relaxes the
invariant that mpLbForm never returns LISTBOX_ENTRY_NOTFOUND.

A signed integer overflow is a problem in itself, but in practice the
SID_HYPERLINK_SETLINK handler in sd::DrawViewShell::FuTemporary() didn't
insert a field, since the insert mode was a large negative value instead
of HLINK_FIELD.

Change-Id: I238d9f662a74f320d05ea6a6cc97319d2d5b3d5a
Reviewed-on: https://gerrit.libreoffice.org/73034Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins

Since Clang doesn't keep backwards binary compatibility, it's necessary
to rebuild when Clang (major version?) changes. This was broken
because e.g. check.cxx didn't include plugin.hxx, and so it didn't depend
on config_clang.h . Now simply force timestamp change if config_clang.h
changes.
This still needs re-running configure though.

Change-Id: Icbc404b37105599f1ca6c8996f5a3d45d50082db
Reviewed-on: https://gerrit.libreoffice.org/72976
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>

This reverts commit efe28895.
It is that commit that is broken. The only thing that does not work is
that not all compilerplugin sources depend on config_clang.h, the rest is fine.
So instead of reverting something that in principle works (and even complaining
in the commit message about the original problem), just fix it
(will do in next commit).

Change-Id: Ic7766a97220d5b7ef1cd195320899564140fdf1c
Reviewed-on: https://gerrit.libreoffice.org/72975
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>

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

* Update helpcontent2 from branch 'master'
  - Explain formatted display in search for Calc
    
    Was missing in the find&replace help page
    
    Change-Id: I6b997fa34d7784be1f143e6403cd645327415cde
    Reviewed-on: https://gerrit.libreoffice.org/73017
    Tested-by: Jenkins
Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>
    

Change-Id: Ib6ab095ea5c4b4a01afad5510208ad352dea5d76

Change-Id: I7602974ed6f4969ec9f79504bdb72758a747d39a
Reviewed-on: https://gerrit.libreoffice.org/72982
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>