Age | Commit message (Collapse) | Author | Files | Lines |
|
... when using Anchor->To Page context menu.
For shapes, in SwDoc::ChgAnchor() and for sw flys in
SwDoc::SetFlyFrameAnchor().
Change-Id: I7d747b2558ef69df99636ea0fb0409deb461a79a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100131
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
Exporting at-page anchored flys to DOCX can result in wrong positions,
because DocxSdrExport::startDMLAnchorInline() converts
text::RelOrientation::FRAME to relativeFrom="column", i.e. the margin,
but sw displays it as relative to the page.
In fact at-page and FRAME is an invalid combination according to the
table in ODF 1.3, 20.298 style:horizontal-pos, the paragraph and
character relations are not valid for page-anchored flys.
Since there are lots of ODT files with this invalid combination, try to
fix it on import, in SwXFrame and SwXShape.
Funnily, SwXShape is attached before the properties are set, while
SwXFrame is attached after the properties are set.
The anchor frame for at-page is always a SwPageFrame.
Unfortunately there is a case where PRINT_AREA and PAGE_PRINT_AREA
differ, namely the CalcClipRect() only handles PRINT_AREA so it will
crop to the right margin with that but not with PAGE_PRINT_AREA,
so don't map this value.
Change-Id: I4d5f7f87d045ac4539b9170e55c34d4afe801f4d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100130
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
so it does not contain the soon to-be-deleted SwTableBox so if the rPam is
queried via a11y it doesn't claim the deleted cell still exists.
tdf#122844 may be the same issue
Change-Id: I1ac3752676162ba5a29c0916039b2b467e2ac41a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100186
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
It seems all 3 places derive from unotest::MacrosTest, so extract the
common code there.
Change-Id: I71a2474a7d6b1623f50575f9e9c43580ba076330
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100185
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I3169e817c2f033d1525adc3b02ac3680ad220d70
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99074
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
so the reset buttons can restore back to the dialogs starting position
Change-Id: I7af1db23d1080e0f57a2ac1db54aca7d56c426f1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100174
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I432dcc61dfb53e6b439052c495a602aab8a58f5d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100172
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
This allows to call collectAutoStyles where required (e.g. when enumerating
used fonts), without side effect of writing table styles XML inside the call,
out of place.
Change-Id: Ida05e373eb8502590c43e2b0e85c3b0c1107c551
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100153
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
so "relative" mode sticks regardless of any rounding issues triggering
the table out of relative mode.
Change-Id: If0abbf2ef75feb6fc4a408966c2a3c350589023f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100161
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
instead of operating on a copy of the original SwTableRep and over
writing the original at commit
Change-Id: I5c42291302f8b4a3394adcdb3425524623f7a051
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100140
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I26c8743b2ecd174e24dc61f796039793eee7e0c0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100160
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
So in case the test fails, it's possible to see the same failure
multiple times.
Change-Id: Ic573807967b004bb7650ffb3614f5006db34080e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100137
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I47e4ec87a007864177d76b46863a87ea8c4b1a23
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100150
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
use a label instead, keep spinbutton (but invisible) to format the label
Change-Id: I36660566df34891e8e813dee24375eacf55e09d3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100127
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
and keep the original around for use from ::Reset and overwrite
the original SwTableRep on commit
Change-Id: I18e078e577382c4c13d6f5e576cc1eeec15a7906
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100072
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I7046814570a3ac98c92dc3d08e8dd05ed4d3483c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100071
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
... and SwDoc::CopyMasterFooter(); this is the same as commit
9f7ee38acec0cb614e37aecc5ea9c5f1c63b61b6 but for 2 other functions that
do the same thing.
Change-Id: Id7ed449a004ee3c9452d4603bf8632e2720651ed
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100077
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
GetMaster() is for right pages. I assume this was a
copy/paste mistake which came in already at initial import.
And since left/right are alternating, they always use
the first version of the header/footer. Although the UI
doesn't allow changing these, they still COULD be different,
as is the case with the unit test.
No existing unit tests even touch this code,
so not a common situation at all.
Change-Id: I9e3720ddf34a8f7e08ce196780fbe16e8c88940b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99628
Tested-by: Justin Luth <justin_luth@sil.org>
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Reviewed-by: Justin Luth <justin_luth@sil.org>
|
|
with expressions like !(a && b)
Change-Id: Id2acec2a8d0eaaa8e5e37dbd2cae7281be36572e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100040
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This patch adds a dedicated hrc file for RID's
of all the properties that can be displayed in
the Inspector
Change-Id: I258ca060508e28b7b66e96393fcef4fd104bb781
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99983
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
63049e98a659290229d3356e76d49cea44575011 "Reliably set up controls of hyperlink
dialog in constructor" fixed an issue that could cause Python UITest code to
issue a bogus SELECT request that would fire an assert in
rtl_uString_newFromSubString. Even if that issue is fixed now, it is probably a
good idea to validate the requested range here.
(An alternative would be to validate it in the underlying shell's SelectText,
but that function is also called from internal code (which presumably already
ensures that it is passing valid arguments), so it is probably better to stay
with that function's narrow interface.)
It would probably be nice if this function reported failure (by throwing a
css::lang::IllegalArgumentException, say) instead of silently (modulo SAL_WARN)
clamping the range, but it is called from Scheduler::ProcessTaskScheduling
(vcl/source/app/scheduler.cxx) in a try/catch block that prohibits all
exceptions.
Change-Id: I5b7b4255861766a81a81501e391b1ff4e09b7db6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99933
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
... and SwTextFly
See tdf#94879 for motivation.
Change-Id: I833b563a03824ae14014cdd418dcfd3b832a9a94
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99984
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Recheck after 7-0 branchoff
Also drop the now unused file include/vcl/field.hxx
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I9e54c82f50d1e02a0f99858939cac999fc66f7de
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99261
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
This check was originally introduced by me for a few toolbar
controllers (save, underline, currency), as an attempt to reuse
the same controllers also for non-split buttons (see tdf#98745
and tdf#101672). But since then it was copy-pasted to other
places where it probably makes no sense.
Change-Id: I7af2a3f5864ced88c91f330e87f32046d0c21383
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99960
Tested-by: Jenkins
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
|
|
The vcl implementation expects menu item attributes to be
set on the sub menu they appear in, not on the parent menu.
Change-Id: I7d6553126ed1dd5c1434529342b776aee01409a3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99954
Tested-by: Jenkins
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
|
|
Seems code never really bothered not to touch default style
info, when inserting from file. Original commit is:
Author: Sascha Ballach <sab@openoffice.org>
Date: Wed Feb 28 08:24:41 2001 +0000
import of default styles added
Change-Id: Ibb639a585bedabdcc5987900ecca1e04f4bb593a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99015
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
Change-Id: I32ce9fcca86de4608939d385f42c43afc46bfb7d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99956
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I90c9ecdaf262fe4e2d84af78b575a00c16634a7a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99890
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
|
|
This only handles lists with PositionAndSpaceMode::LABEL_ALIGNMENT.
TODO: handle PositionAndSpaceMode::LABEL_WIDTH_AND_POSITION.
TODO: handle NumberingType::BITMAP.
It doesn't align number according to Adjust, since that requires to
use a tab stop at the number position with appropriate alignment, and
it's unclear how would that interact with LabelFollowedBy modes other
than LISTTAB.
When first tab stop position is greater than ParaLeftMargin, Writer
uses left margin as implicit tab stop position, thus in this case
list appearance is different from processed text appearance.
In case of justified paragraphs, space after number (which does not
participate in justification when part of numbering) becomes part
of justification after conversion to text.
Change-Id: I88ad6617f8a09307ecad9d28edee92a59c68a4d4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99939
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I0116fe288b97d22c3f170f139fe95cfd06d89d8f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99935
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
For the content of the selection it should not make a difference if that range
is "backward" or "forward", but the latter looks cleaner.
Change-Id: Ibc27ac257c9338f9b17ace10fbec938b1db394eb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99932
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
They had been added with 27798238ecb200e0753b013c79df0e6c014c7a7a "uitest :
Avoid any timing issue in test_insert_hyperlink" and
1cdda798def040fe778348061c0e18b28aa0e6bd "Further timing issues with
test_insert_hyperlink", but 63049e98a659290229d3356e76d49cea44575011 "Reliably
set up controls of hyperlink dialog in constructor" now argues that they are
probably not necessary after all: For one, they had presumably been added as
blind fixes, without actually understanding what's going on (that's at least
true for the second, monkey-see-monkey-do one by me). And for another, after I
had seen their failures frequently with my local ASan+UBSan Linux build, I
haven't seen them at all in lots of executions of that test with the
63049e98a659290229d3356e76d49cea44575011 fix included.
So lets assume that those "magic" calls are indeed not necessary after all. If
we run into trouble again, they can be added back.
Change-Id: I6f4417c9fd243758a03a4de05270f342e7147d27
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99931
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I073545c11e2261703e5255abefaf82a2bbea5211
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99934
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I67fd1a269d960174b88c57da4a0588f5d9252660
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99885
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: If7738d47ec0273f24eee99b7336380cfa78c1243
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99896
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I8d62f001f3a13463d25b8ec16e3cabd43e3abd70
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99898
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Id0b37a9060ab77ecfd8c4aa2b340ab7b958ba109
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99897
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I42f9dd59300f215b6d8ff9f73a9f6893dbb9a8be
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99899
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I737296f1a0646065288be2cb0be3ef7f939fb536
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99878
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Change-Id: If74f1cfca114d52566164656c34a0764cfbaad43
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99886
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I64f743d6f696584ff4c3c9185ae1e8fa42451677
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99884
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I086860cefe9f26c3728fe0d8266c35dae37b9570
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99887
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
A follow-flow-line SwRowFrame is deleted in RemoveFollowFlowLine()
while it is being iterated in stack frame #18.
0 SwRowFrame::~SwRowFrame() (this=0xaa035b0, __in_chrg=<optimized out>) at sw/source/core/layout/tabfrm.cxx:3807
1 SwFrame::DestroyFrame(SwFrame*) (pFrame=0xaa035b0) at sw/source/core/layout/ssfrm.cxx:389
2 SwTabFrame::RemoveFollowFlowLine() (this=0x9c16790) at sw/source/core/layout/tabfrm.cxx:945
3 SwTabFrame::MakeAll(OutputDevice*) (this=0x9c16790, pRenderContext=0x72afaf0) at sw/source/core/layout/tabfrm.cxx:2203
4 SwFrame::PrepareMake(OutputDevice*) (this=0x9c16790, pRenderContext=0x72afaf0) at sw/source/core/layout/calcmove.cxx:370
5 SwFrame::Calc(OutputDevice*) const (this=0x9c16790, pRenderContext=0x72afaf0) at sw/source/core/layout/trvlfrm.cxx:1791
6 SwFrame::PrepareMake(OutputDevice*) (this=0x925b740, pRenderContext=0x72afaf0) at sw/source/core/layout/calcmove.cxx:248
7 SwFrame::Calc(OutputDevice*) const (this=0x925b740, pRenderContext=0x72afaf0) at sw/source/core/layout/trvlfrm.cxx:1791
8 SwFrame::PrepareMake(OutputDevice*) (this=0x925b8e0, pRenderContext=0x72afaf0) at sw/source/core/layout/calcmove.cxx:248
9 SwFrame::Calc(OutputDevice*) const (this=0x925b8e0, pRenderContext=0x72afaf0) at sw/source/core/layout/trvlfrm.cxx:1791
10 SwFrame::PrepareMake(OutputDevice*) (this=0x925ba70, pRenderContext=0x72afaf0) at sw/source/core/layout/calcmove.cxx:248
11 SwFrame::Calc(OutputDevice*) const (this=0x925ba70, pRenderContext=0x72afaf0) at sw/source/core/layout/trvlfrm.cxx:1791
12 SwFrame::MakePos() (this=0x925bc20) at sw/source/core/layout/calcmove.cxx:552
13 SwTextFrame::MakePos() (this=0x925bc20) at sw/source/core/text/frmform.cxx:339
14 SwContentFrame::MakeAll(OutputDevice*) (this=0x925bc20) at sw/source/core/layout/calcmove.cxx:1408
15 SwFrame::PrepareMake(OutputDevice*) (this=0x925bc20, pRenderContext=0x72afaf0) at sw/source/core/layout/calcmove.cxx:370
16 SwFrame::Calc(OutputDevice*) const (this=0x925bc20, pRenderContext=0x72afaf0) at sw/source/core/layout/trvlfrm.cxx:1791
17 SwContentFrame::CalcLowers(SwLayoutFrame&, SwLayoutFrame const&, long, bool) (rLay=..., rDontLeave=..., nBottom=168478, bSkipRowSpanCells=true) at sw/source/core/layout/tabfrm.cxx:1521
18 lcl_RecalcRow(SwRowFrame&, long) (rRow=..., nBottom=168478) at sw/source/core/layout/tabfrm.cxx:1651
19 SwTabFrame::MakeAll(OutputDevice*) (this=0x93ec7e0, pRenderContext=0x72afaf0) at sw/source/core/layout/tabfrm.cxx:2421
20 SwFrame::PrepareMake(OutputDevice*) (this=0x3df3cc0, pRenderContext=0x72afaf0) at sw/source/core/layout/calcmove.cxx:316
21 SwFrame::Calc(OutputDevice*) const (this=0x3df3cc0, pRenderContext=0x72afaf0) at sw/source/core/layout/trvlfrm.cxx:1791
22 GetFrameOfModify(SwRootFrame const*, SwModify const&, SwFrameType, SwPosition const*, std::pair<Point, bool> const*) (pLayout=0x72aa850, rMod=..., nFrameType=(SwFrameType::Txt | SwFrameType::NoTxt), pPos=0x71f35e0, pViewPosAndCalcFrame=0x7ffc99f591a0) at sw/source/core/layout/frmtool.cxx:3697
23 SwContentNode::getLayoutFrame(SwRootFrame const*, SwPosition const*, std::pair<Point, bool> const*) const (this=0x6fcfb50, _pRoot=0x72aa850, pPos=0x71f35e0, pViewPosAndCalcFrame=0x7ffc99f591a0) at sw/source/core/docnode/node.cxx:1194
24 SwCursorShell::GetCurrFrame(bool) const (this=0x72a9730, bCalcFrame=true) at sw/source/core/crsr/crsrsh.cxx:2455
25 SwFEShell::GetAnyCurRect(CurRectType, Point const*, com::sun::star::uno::Reference<com::sun::star::embed::XEmbeddedObject> const&) const (this=0x72a9730, eType=CurRectType::PageCalc, pPt=0x0, xObj=empty uno::Reference) at sw/source/core/frmedt/fews.cxx:113
26 SwView::StateStatusLine(SfxItemSet&) (this=0x72af430, rSet=SfxItemSet of pool 0x6fa3d50 with parent 0x0 and Which ranges: [(10000, 10000), (10221, 10221), (10223, 10225), (11064, 11065), (21182, 21182), (21185, 21185), (21189, 21189)] = {...}) at sw/source/uibase/uiview/view2.cxx:1517
Not obvious why this changed with calling MakeFrames() instead of
SwNodes::CopyNodes(bNewFrames=true) or how to best prevent it; adding
another FrameDeleteGuard avoids the crash at least.
(regression from 166b5010b402a41b192b1659093a25acf9065fd9)
Change-Id: Ifd5a0c93064c9536429dda30a2c4ebc7a31b7e7d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99870
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
The pasted table does get a SwTabFrame but the problem is that
TurboAction() is called and formats the pre-existing SwTextFrame and
somehow that just sets all the valid flags on the new SwTabFrame without
doing any formatting.
Previously, SwNodes::CopyNodes(bNewFrames=true) would call
SwTabFrame::Paste() which invalidates the page.
In InsertCnt_(), for new SwSectionFrames InvalidatePage() is already
called so do the same for SwTabFrame which gets rid of the "turbo".
(regression from 166b5010b402a41b192b1659093a25acf9065fd9)
Change-Id: I970a04bd8e76f5418bddb66af915ac466f44daf3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99867
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
Change-Id: I0003a190cbc42845274d71f8f157977e598a3fd4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99859
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I793811af353fe61b12e5e89da2056fb58108e9dc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99852
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I34662fd439578fc6f446c5216c5c1b735b79718d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99860
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ia296fc6e6c8f78edf533dedf52996560ae62d143
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99853
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
... of document; the root cause is that in some intermediate delete
operation, the delete will remove a section start/end node pair that
surrounds the last text node in the document, but
SwUndoDelete::RedoImpl() will not remove it, thus for subsequent Undo
actions the indexes are messed up and weird things happen.
Fix this in DocumentContentOperationsManager::DeleteRangeImplImpl(),
with the same weird "is point at the end" check as SwUndoDelete.
Change-Id: Iebf20d3c129c69692df8d57e3c5b9e6fec281e4b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99810
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
Change-Id: If96b2484426f0d09119ca89943729c149675156f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99851
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|