regression since...
commit 0677d46bcc
Author: Caolán McNamara <caolanm@redhat.com>
Date: Wed May 20 15:22:56 2020 +0100
FmXListBoxCell doesn't need to implement css::awt::XListBox
It seems just addItemListener/removeItemListener are needed, stub
the rest to make sense just for single-selection mode and avoid
the return of the apparently unused multi-selection complexity
Change-Id: I46a32bdd23d44273da37cc21cfa45de907674f31
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100746
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
i.e. ResourceMenuController + GenericPopupToolbarController.
(Decl. of both isn't available in a header file, so they are instantiated
via the service manager for now. This is a bit weird for something from
the same module, but should not make any difference in practice.)
Change-Id: Ia3fc7ba82b0f6e1a43aa7b5e56e2cff7e039d877
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100725
Tested-by: Jenkins
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
If a merged paragraph has no extents, a fly anchored at the start or at
the end should be shown.
(regression from 28b77c89df)
Change-Id: I78135f3c033cf08aad81c86b0ac693528e3f3f8e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100543
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
Added in commit 2edc86a592 (Default all
tests to run with the svp plugin, 2018-11-23), if svp is to be avoided,
it has to be filtered out from the environment variables, not filtered
for.
With this, the unexpected SAL_USE_VCLPLUGIN=gen is gone from the
generated cmdline when using gb_CppunitTest_use_vcl_non_headless.
Change-Id: Ib666f3df007898165f2019f0a9b0677f679aa6e1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100742
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
the properties panel uses huge min/maxes which can overflow
when the number of digits changes
Change-Id: Idbb998a065ce8f2b918fceea2076b794cbde3368
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100731
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
It is better to let the exception be uncaught and then catch that in
the debugger, or let our crashpad handler capture a full
stack-trace and report it.
Change-Id: If5a4259c22c9f47d788e01725c802eeeb46162e3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94596
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
as formula fields instead of exporting only cell
text content.
Only unmodified formula fields were exported from
commit d42776e01b
(tdf#118682 DOCX: export formula fields).
Now newly added Writer formula cells or modified
table formula fields imported from DOCX (which are
converted to formula cells after formula editing)
are exported.
Change-Id: Iecec75b2a36b94c2d3aa998603ac10ea2f2b8d4e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100667
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
Since .doc and rtf don't postpone flys, they shouldn't also be
postponing the text.
Partially revert my LO 5.3 commits b39feae4f12b07a0fdb2c8c2a48d5aae613cd7c9/
3ade281c1d
which only avoided postponing within tables for the .doc format,
since this patch eliminates it completely for .doc and .rtf
I think the original Synerzip LO 4.4 patch
commit 80fd9fb720
was only intended for DOCX formats.
I am concerned about doing this since the implications are unclear,
but I take comfort in seeing that many synerzip commits just
need to be reverted, and that a number of .doc bugs are
solved by doing this. The fact that few bug reports have
been made since 4.4 also suggests this isn't a hugely
active area. No intention to backport, and still lots of testing
time available for LO 7.1.
Change-Id: I9284d3cc516c480e8bb0848c17797988ffcdcd2c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100175
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
This removes the only place that hadn't used transparent impBufferDevice
yet - in VclProcessor2D::RenderMaskPrimitive2DPixel. Not clearing the vdev
made it draw on whatever garbage was left there from previous paints when
the buffer was taken from maFreeBuffers in VDevBuffer::alloc, so since this
was also the only place left that didn't clear the buffer explicitly, this
makes the clear unconditional in impBufferDevice ctor.
Also this makes sure to clear proper rectangle in VDevBuffer::alloc, and to
clear mpAlphaVDev in OutputDevice::Erase.
Change-Id: I7c1c0cc510a92628f19020b3faf0c0cd81f5a599
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100674
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
MSWordExportBase::NeedTextNodeSplit() simply uses the soft-page-break
positions to potentially insert section breaks - but now that Writer can
display field instructions, it's quite silly to insert section breaks
inside them.
Change-Id: Ie57e6281a0287aac36984e5467920852db19a8ad
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100661
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
This hit assert(bSavePos && bSaveOtherPos);
Tweak SwUndoSaveContent::DelContentIndex() for fieldmarks to only accept
an equal end position if the start position was in range as well.
(regression from 24fd14b387)
Change-Id: If6c9b049193bb7f1bc39ec66d1c965512f9d6ec1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100660
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
commit dce1d0766c
Author: Caolán McNamara on Mon Oct 14 13:24:31 2002 +0000
#i2916# integrate markm character anchoring export impl
1.) if (nPos >= nStartPos && nPos <= nMinPos)
2.) nMinPos = nPos;
3.) ++nPos;
4.) if (nPos >= nStartPos && nPos <= nMinPos)
5.) nMinPos = nPos;
So lines 3/4/5 should be dead code.
With lines 1 and 2, MinPos has changed to be nPos,
so if we increment nPos, by definition it will now be
larger than itself (aka MinPos).
There is ONLY one time when this could have been used,
and that is if nPos == nStartPos - 1.
However, in that case the fly WILL ALREADY BE HANDLED,
because it is in the current run's position.
So if the fly is already going to be handled,
what good will treating the next character
separately do?
So the comment sounds really important, but in practice
it seems as if it is not happening.
Plus round-tripping already breaks everything anyway,
so very unlikely to raise any substantial regressions.
Change-Id: Ifa867ac3614aef82a3dde358ee3e5bd54d5a1142
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100386
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
* gcc3_linux_aarch64 needs a hack to detect the reserve member in LLVM >= 10
libcxxabi __cxa_exception, in addition to the existing hack for LLVM 5.
On macOS arm64 (which shares the bridges/source/cpp_uno/gcc3_linux_aarch64/
code) we know that we always target a >= LLVM 10 libcxxabi, so we do not need
neither of the two hacks there.
(And a7d1fed245 "Hack to dynamically adapt to
__cxa_exceptiom in LLVM 5.0 libcxxabi" had introduced a "fillUnoException" vs.
"mapException" typo in the comment when it copied it from
bridges/source/cpp_uno/gcc3_macosx_x86-64/except.cxx.)
* Similarly, gcc3_linux_x86_64 needs both hacks when it is built against
libcxxabi (and the need for the LLVM 5 hack had gone unnoticed there for now).
* It is not clear to me now why gcc3_macosx_x86-64 needs the LLVM 5 hack (which
I even initially developed for that platform,
7a9dd3d482 "Hack to dynamically adapt to
__cxa_exceptiom in LLVM 5.0 libcxxabi") but not the LLVM >= 10 hack (although
it does need the corresponding hack in fillUnoException when running against
recent upstream LLVM trunk libcxxabi, f4b6f6a8ae
"Hack to dynamically adapt to __cxa_exceptiom in LLVM 11 libcxxabi".
Change-Id: I8e7a5c871fbeeaf82bbd16fa03e73f10f229da93
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100656
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
- Backing code for private:image/3242 was removed in commit
367fedcc44 ("loplugin:unusedenumconstants")
for unclear reasons. Fortunately it's used for a .uno:NewDoc menu item,
so an appropriate icon can be retrieved using that command.
- private:image/3216 was removed in commit
2559cab126 ("FDO#42454 - EasyHack: remove
code associated with unused icons"). No idea how it worked, or whether
it was already broken at this point.
Change-Id: If5c43626a1334c27604409bcf7eb5920930430db
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100450
Tested-by: Jenkins
Reviewed-by: Rizal Muttaqin <riz_17_oke@yahoo.co.id>
and simplify the destruction - we only ever called ReleaseInterface
on destruction, so no need to bother with that, and risk touching
pointers that might be nullptr
Specifically, the problem is this code
pImpl->pSlotPool.reset();
which triggered the path
~SfxSlotPool -> ~SfxInterface -> SfxGetpApp()->GetAppSlotPool_Impl()
which crashes because the pSlotPool pointer is null at that point
Change-Id: I8577760d09be598926623d6eb5500969e07dd6f8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100624
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...in LLVM 10 libcxxabi, same as f4b6f6a8ae "Hack
to dynamically adapt to __cxa_exceptiom in LLVM 11 libcxxabi" for
gcc3_macosx_x86-64 and 986bd28388 "ofz#24641
libc++abi __cxa_exception has grown another member" for gcc3_linux_x86-64.
(Note that 91c8a3f3e7 "The
__cxa_exception::reserve member has been backported to LLVM 10 libcxxabi" found
out that this is already relevant for LLVM 10, contrary to the mentioned
commits' subject lines.)
On macOS arm64 (which shares the bridges/source/cpp_uno/gcc3_linux_aarch64/
code) we know that we always target a >= LLVM 10 libcxxabi, so we do not need
the hack there.
Change-Id: I49e3d5b06b0b427ee3edeb10281025e4b9f2615f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100644
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
