Change-Id: I23671f0cea592c92a05b34b3cf284a47a73962b1

Change-Id: I96f91105d32b18c29bd82eedcf2f93c54ad5f229

If nCnt = 0 the only thing that will happen is an infinite loop.

Change-Id: I23c5d0ff9d36fbfb3eabc93476fe3ca1c558f91c

Change-Id: I093c8fbf5bb181d8e530fe33805a16aea94cdd62

SwTextNode::EraseText() on the paragraph at the start of the
selection notifies the SwTextFrame:

0  in SwFrame::ImplInvalidateSize() (this=0x3088a20) at sw/source/core/layout/wsfrm.cxx:1568
1  in SwFrame::InvalidateSize() (this=0x3088a20) at sw/source/core/inc/frame.hxx:849
2  in SwTextFrame::InvalidateRange_(SwCharRange const&, long) (this=0x3088a20, aRange=..., nD=-62) at sw/source/core/text/txtfrm.cxx:741
3  in SwTextFrame::InvalidateRange(SwCharRange const&, long) (this=0x3088a20, aRange=..., nD=-62) at sw/source/core/text/txtfrm.cxx:708
4  in SwTextFrame::Modify(SfxPoolItem const*, SfxPoolItem const*) (this=0x3088a20, pOld=0x0, pNew=0x7ffc8da38c50) at sw/source/core/text/txtfrm.cxx:1005
5  in SwClient::SwClientNotify(SwModify const&, SfxHint const&) (this=0x3088a20, rHint=...) at sw/source/core/attr/calbck.cxx:67
6  in SwModify::CallSwClientNotify(SfxHint const&) const (this=0x2f05550, rHint=...) at sw/inc/calbck.hxx:355
7  in SwModify::ModifyBroadcast(SfxPoolItem const*, SfxPoolItem const*) (this=0x2f05550, pOldValue=0x0, pNewValue=0x7ffc8da38c50) at sw/inc/calbck.hxx:176
8  in SwModify::NotifyClients(SfxPoolItem const*, SfxPoolItem const*) (this=0x2f05550, pOldValue=0x0, pNewValue=0x7ffc8da38c50) at sw/source/core/attr/calbck.cxx:142
9  in SwTextNode::EraseText(SwIndex const&, int, SwInsertFlags) (this=0x2f05550, rIdx=SwIndex (offset 1), nCount=62, nMode=SwInsertFlags::DEFAULT) at sw/source/core/txtnode/ndtxt.cxx:2355
10 in SwUndoDelete::SaveContent(SwPosition const*, SwPosition const*, SwTextNode*, SwTextNode*) (this=0x3052950, pStt=0x7ffc8da390b8, pEnd=0x7ffc8da39100, pSttTextNd=0x2f05550, pEndTextNd=0x2faefe0) at sw/source/core/undo/undel.cxx:387

However, at this point the first page, which contains this paragraph, is
not visible; so the Action that is created in ViewShell::ImplEndAction()
will skip over the first page and start at the 2nd page, which is the
first visible one.

Now it happens that the last paragraph in the document has a page break
on it, and formatting it causes it to move forward (a new page to be
inserted and the empty 2nd page to be deleted).

Unfortunately it then decides to reset the mbValidSize flag on the
preceding SwTextFrame, assuming that it was set by its own moving
forward, and not already set before.

0  in ValidateSz(SwFrame*) (pFrame=0x3088a20) at sw/source/core/layout/calcmove.cxx:1082
1  in SwContentFrame::MakeAll(OutputDevice*) (this=0x308b4a0) at sw/source/core/layout/calcmove.cxx:1276
2  in SwFrame::PrepareMake(OutputDevice*) (this=0x308b4a0, pRenderContext=0x306f850) at sw/source/core/layout/calcmove.cxx:346
3  in SwFrame::Calc(OutputDevice*) const (this=0x308b4a0, pRenderContext=0x306f850) at sw/source/core/layout/trvlfrm.cxx:1760
4  in SwLayAction::IsShortCut(SwPageFrame*&) (this=0x7ffc8da394a0, prPage=@0x7ffc8da392b8: 0x7491e30) at sw/source/core/layout/layact.cxx:1085
5  in SwLayAction::InternalAction(OutputDevice*) (this=0x7ffc8da394a0, pRenderContext=0x306f850) at sw/source/core/layout/layact.cxx:490
6  in SwLayAction::Action(OutputDevice*) (this=0x7ffc8da394a0, pRenderContext=0x306f850) at sw/source/core/layout/layact.cxx:351
7  in SwViewShell::ImplEndAction(bool) (this=0x30829c0, bIdleEnd=false) at sw/source/core/view/viewsh.cxx:278
8  in SwViewShell::EndAction(bool) (this=0x30829c0, bIdleEnd=false) at sw/inc/viewsh.hxx:605
9  in SwCursorShell::EndAction(bool, bool) (this=0x30829c0, bIdleEnd=false, DoSetPosX=false) at sw/source/core/crsr/crsrsh.cxx:258
10 in SwActContext::~SwActContext() (this=0x7ffc8da396a0, __in_chrg=<optimized out>) at sw/source/core/edit/edws.cxx:159
11 in SwWrtShell::DelRight() (this=0x30829c0) at sw/source/uibase/wrtsh/delete.cxx:260

So at the end of the Action, the first page is still not valid, and
the SwTextFrame has mbValidPos = false, but it does have
mbValidSize = true.

Then when the SwCursorShell::UpdateCursor() calls
SwViewShell::MakeVisible(), which creates another Action, the
SwTextFrame is not formatted and its SwTextPortions do not match
the paragraph text content, which is the cause of the crash.

Change-Id: I6e8153c574469a94d190fda8bc3007d17a474c7f

getWordBoundary() can return bounds that do not include the starting
nPos, if there are ZWSP characters at the starting position.

This happens in the bugdoc of tdf#109081 where paragraph starts with 3
ZWSP and then 5 dashes, SwScanner is created from 0 to 1 and bounds are
3 to 8.

Change-Id: I5fc41b98568a7211fc7d5f29bb87840371a4c005

to getOleSourceRanges( renamed from getChartSourceRanges)
and optionally calculate source ranges to avoid code
duplication and do OLE detection as done in
CheckOle() which was working well before the commit
c55d5226.

Matching test cases (in uitest) coming up soon in another commit.

Change-Id: I64a12eef02afb488bed4bc8de1a18823c89128bb
Reviewed-on: https://gerrit.libreoffice.org/40278Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jean-Baptiste Faure <jbfaure@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>

ScXMLDataPilotTableContext
ScXMLDPSourceSQLContext
ScXMLDPSourceTableContext
ScXMLDPSourceQueryContext
ScXMLSourceServiceContext
ScXMLDataPilotGrandTotalContext
ScXMLSourceCellRangeContext
ScXMLDataPilotFieldContext
ScXMLDataPilotFieldReferenceContext
ScXMLDataPilotLevelContext
ScXMLDataPilotDisplayInfoContext
ScXMLDataPilotSortInfoContext
ScXMLDataPilotLayoutInfoContext
ScXMLDataPilotSubTotalsContext
ScXMLDataPilotSubTotalContext
ScXMLDataPilotMembersContext
ScXMLDataPilotMemberContext
ScXMLDataPilotGroupsContext
ScXMLDataPilotGroupContext
ScXMLDataPilotGroupMemberContext
ScXMLDPFilterContext

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

Change-Id: Iedd529d4b5064beed3d2fd99cfe4e0312c024187

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

This was the last incarnation of SfxItem binary stream serialization that is to
be eliminated after clipboard use is gone.

The "full" EditTextObject::operator==() in EditTextObjectImpl::operator==(),
and via ContentInfo::operator==() in SfxItemSet::operator==(), also compare the
SfxItemPool pointers which gets in the way here (not stored to stream hence
didn't matter and maybe the reason for not having switched EETextObjEqual() to
use operator==() back in the days).

Introduce *::Equals() functions that do not compare pool pointers and let
SfxItemSet::Equals() in that case not assume it would be operating on one pool
only.

Change-Id: Ifff939a92101c7f74695b676a45a7fdbb4f1d7f6
Reviewed-on: https://gerrit.libreoffice.org/40492Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins <ci@libreoffice.org>

Change-Id: I765c482a41e9681a1eb145c1833cc94f35a27db3

so it gets progressively slower

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

with global label placement setting if available while
importing xls chart.

Added unit test in chart2import.cxx that asserts one of
the point label setting in the bugzilla xls document.

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

A text range represents a selection or cursor position, so similar to
sections or tables, it makes sense to expose the containing paragraph as
well. This new property does exactly that.

Change-Id: If92a3b5e61f13c7c14ca52bc8593a2b286a596cc
Reviewed-on: https://gerrit.libreoffice.org/40483Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>

The invocation of make fetch added in commit
fe3fb5ec didn't do anything because
the force-restart didn't actually restart make because it touched
"Makefile" but the make read "$(BUILDDIR)/Makefile", and make isn't
smart enough to notice those are the same.

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

all this foo is ultimately animated gifs and the count there is
limited to unsigned 16bit

Change-Id: Ib6e6dde7355f3619bb7735743e686e6338a235ee

Change-Id: I7cc7531d6a1770edd8b644c6958b91275a53dd84

and remove PushButton::IsValueChangedFromSaved

Change-Id: Ib1c51e27fd708c5d4811c90ef5659b4d55dd8860

inheriting the IsValueChangedFromSaved from PushButton has allowed
undesirable behaviour to be selected

Change-Id: Ifccb1657d2565005e6f9e239c6118f2e5ae7970c

Change-Id: Ic325b79f04e04aa19e08a60db30b982d90f04c80
Reviewed-on: https://gerrit.libreoffice.org/40480Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>

using some wrappers around callee and caller AST nodes

Change-Id: I599a04a18caa3ada70bcb266e228208b7a81f1a1

Problem:

1. (a) copied April
2. (a) pasted -> April
3. (b) copied March
4. (a) pasted -> March [should have been April]

where (a), (b) are different views

Solution:
A real solution would require to have one clipboard per view.
This patch is only a workaround, which doesn't allow to paste content
which has been copied in a different view; it takes also care to
disable the "Paste" entry in the context menu.

Change-Id: I3254f130af106299b0b519884a4ca03db08fc4c8
Reviewed-on: https://gerrit.libreoffice.org/40459Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jan Holesovsky <kendy@collabora.com>

Change-Id: I41f153af55262d201c0fb024460de0e9f1c14670
Reviewed-on: https://gerrit.libreoffice.org/40472Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>

Change-Id: I0ba463fcaff4c449f762a7969e0feab659b37adf
Reviewed-on: https://gerrit.libreoffice.org/40471Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>

Change-Id: Id0aa4ced8644ddbee9e1a0453887f07907547aae

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

Change-Id: Ifa9fda35020d456338781879df9fba4c0ee535fd
Reviewed-on: https://gerrit.libreoffice.org/40469Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>

Browsers don't recognize base64 svg if the mimetype is missing.
So we add the image mimetype to our flat odf export, which the xhtml
export uses and transforms it into an xhtml document.

Change-Id: I21aafdb97b4104e14e2d40abda73a526bb37041a
Reviewed-on: https://gerrit.libreoffice.org/40371Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>

Replace the stopgap type sal_uLong as SvNumberFormatter
format index uses sal_uInt32.

SwInsertDBColAutoPilot uses format indices from SvNumberFormatter and
from the property "FormatKey" which is stored as sal_Int32 but ctor
guards against negative values.

Change type of loop variable in SwCaptionDialog to avoid narrowing
in GetFormatStr/GetFormatKey.

Change-Id: I79980696c07760f7ff026bb1bacf0e069363898c
Reviewed-on: https://gerrit.libreoffice.org/40464Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>

Change-Id: I5e8b3e472caa058c4c8f10b423783d963a6ab1c0
Reviewed-on: https://gerrit.libreoffice.org/40465Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>

signature of Date and Date::DateToDays is
(sal_uInt16 d, sal_uInt16 m, sal_Int16 y)
same types as css::util::Date members Day, Month and Year

Change-Id: Ifa35574d2d335f7bf816dd5209988f4eaf7c5ac2
Reviewed-on: https://gerrit.libreoffice.org/40462Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>

and fix a bug in the plugin itself when calling operator's like the one
on std::function<>

Change-Id: I1617607107eeff06785c1841f69e13ad2926218e
Reviewed-on: https://gerrit.libreoffice.org/40446Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>

Also visualisers for uno_Any and SwNode are tweaked.
Visualisers for uno::Reference, rtl::Reference and VclPtr added.
SwFrameFormats visualiser reimplemented to follow implementation
of boost::multi_index_container.
Minor reformatting.

Change-Id: I24ccb8bfccd7f7514697ca3f36490672ad549aef
Reviewed-on: https://gerrit.libreoffice.org/40466Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>

... chaining down to EditTextObjectImpl::operator==() that compared unique_ptr
instead of content with ContentInfo::operator==() that needed to use
XEditAttribute::operator==() instead of comparing pointers. That resulted in
always false..

Wrong as a chain of

    commit 5a7a4325
    Date:   Tue Nov 10 14:59:05 2015 +0200

        editeng: boost::ptr_vector->std::vector<std::unique_ptr>

and

    commit 4ff5a555
    Date:   Tue Jan 19 15:17:30 2016 +0200

        loplugin:unusedmethods

Plus XEditAttribute::operator==() was wrong since

    commit 71158788
    Date:   Thu May 4 08:11:41 2006 +0000

        INTEGRATION: CWS impressc03u3 (1.8.40); FILE MERGED
        2006/04/27 12:33:10 cl 1.8.40.1: #i64360# fixed operator==

that (to fix a crash comparing items of different types) changed

-            ( (pItem == rCompare.pItem) || (*pItem == *rCompare.pItem));
+            ( (pItem == rCompare.pItem) ||
+            ( pItem->Which() != rCompare.pItem->Which()) ||
+            (*pItem == *rCompare.pItem));

so returning true if Which-IDs differed, instead of

+            ((pItem == rCompare.pItem) ||
+             ((pItem->Which() == rCompare.pItem->Which()) &&
+              (*pItem == *rCompare.pItem)));

Change-Id: I8300c04001e98cb71e520bbe2c180aec0c0a3333
Reviewed-on: https://gerrit.libreoffice.org/40455Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins <ci@libreoffice.org>

As reported at e.g.
<https://ask.libreoffice.org/en/question/90346/building-libreoffice-in-cygwin-leads-to-infinite-loop/>,
sometimes MSVC (seen with 2013 on libreoffice-5-2, but there is no
indication that 2015 on master would be different) emits CR characters
at the end of filenames, resulting in unnecessary rebuilds at per-module
builds, and actually to an infinite loop when doing toplevel make.

Given that CR characters are unexpected in any filenames, it should be
safe to just strip those away unconditionally.

Change-Id: I3d56670b4d930a32489f889085711bfd436de82a
Reviewed-on: https://gerrit.libreoffice.org/40452Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>

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

Change-Id: Ia70f713cdfe2b532dfa4b8aa7876f830b3ef8175

by replacing createFromAscii with OStringToOUString + RTL_TEXTENCODING_UTF8

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

where vcl transparency is the opposite of cairo's so we've been switching the
source color to the opposite for drawing on CAIRO_FORMAT_A1 and then sucking
out the bits "as-is" to give the right results.

Now instead use the right source color and toggle CAIRO_FORMAT_A1 bitmaps to
N1BitLsbPal in getBitmap.

Then additionally toggle all N1BitLsbPal bitmaps input to drawBitmap to
CAIRO_FORMAT_A1 when making a cairo surface from them.

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