The problem was unhandled exception thrown from destructor, resulting
in a crash.
Change-Id: Ib9d2deb2fe9745bf8df060c4e5bf6436b4ca468d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170790
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
and
cid#1607722 Use of auto that causes a copy
cid#1557606 Use of auto that causes a copy
cid#1557569 Use of auto that causes a copy
cid#1556239 Use of auto that causes a copy
cid#1556043 Use of auto that causes a copy
cid#1554961 Use of auto that causes a copy
cid#1554818 Use of auto that causes a copy
Change-Id: I9f74c7bc4da2c6b1df80d0fb4504dd4d03eb1053
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170784
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
std::vector::clear() appears to delete elements in the
reverse order added. In the case of tdf#161729, a style
sheet's SfxItemSet can have a parent SfxItemSet and that
parent is the SfxItemSet for a style sheet added later.
Deleting from the end of the vector deletes a style sheet
and its SfxItemSet. If the now deleted SfxItemSet is a
parent SfxItemSet of a style sheet that was added earlier,
the style sheet added earlier will now have an SfxItemSet
with its parent set to an already deleted pointer. And so
a crash will occur when that earlier style sheet is deleted.
rxStyleSheet.clear();
Change-Id: I8ce7023fce8b01432cb3c9288a8f83e7a2f0f2d8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170707
Tested-by: Jenkins
Reviewed-by: Patrick Luby <guibomacdev@gmail.com>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
The problem was, that importing an HTML table into Firebird, and creating
a primary key, called OParameterUpdateHelper::updateInt for each record's
primary key field. Since commit c07548447a
(Related: tdf#108057 Use autoincrement for automatically added primary key,
2024-03-20), the type of autocreated primary key in Firebird databases is
SQL_INT64, and before this change, OPreparedStatement::setInt failed when
the real field's type wasn't strictly SQL_LONG.
This allows Firebird SDBC's integral OPreparedStatement::set* methods to
promote to larger numeric types capable to represent the values.
Change-Id: I7615c8e9ffa29271d04cf264bb950cb76946dfd6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170787
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
Also add a test for uno.DeleteAllAnnotation
Change-Id: Icc8cfbad50879b5bc0e9e2b9996666cff0a85cb1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170780
Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Open the bugdoc, the first paragraph is meant to be sans and the second
paragraph is meant to be serif, but both of them are serif.
The bugdoc uses the fonts 'IBM Plex Sans' and 'IBM Plex Serif', which is
not something we bundle, so the font fallback is expected, but the
fallback should have a matching font family (roman vs swiss).
Fix the problem by implementing support for <w:family w:val="..."> in
the DOCX import, which was just ignored previously.
Now the DOCX import result in on par with the ODT import result.
Change-Id: I321b9fc6f63126ca5ad61af57af8a5bc7456d5b4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170772
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
This will link libgssapi_krb5.so.2 which is in krb5-libs (ABI CL1 in
RHEL8, ABI CL2 in RHEL9).
Change-Id: I2dbaa64e70f4502c5a47c6c85123c94b9ad41277
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170758
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Make the generated unique ID random for new content controls.
This way if we copy paste them from different documents,
they may still be unique.
Change-Id: I2adb6577e08b5798ae88a63b6178352aa76280d6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170773
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
They are quite slow, and we want to reduce usage of them
Change-Id: Idae1d6035942d29d67269a22b2a771616ea836af
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170775
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
They are quite slow, and we want to reduce usage of them
Change-Id: I5ab3b55e9270419877a08dd1d711ba2fa757a1b5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170774
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
which shows up when navigating large complex documents with
lots of shapes
Change-Id: I0631daf1365387f1192815402921ada191ab6046
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170760
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
"Remember password" will also remember whether the "Use system
credentials" was checked. Rename it to "Remember credentials" and place
it at the bottom of the dialog.
Change-Id: I672715edfa2080a325a0c492b53d6461591e1192
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170752
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Tested-by: Jenkins
There's still the `ImmutableViewportMetrics` class that
actually gets used.
Change-Id: I4645a33812441a2de36d666423742b164da76bda
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170766
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
based on a comment from vmiklos
Change-Id: Ic627ec5eeee35c8a81854e083814c57c151bac13
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170770
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
There are some Arabic, etc numbering options in there that cause gtk to
allocate a large odd-looking height for the combobox.
What we can try is to remove top/bottom padding for this widget, but
then sync it with a sizegroup to another combobox and then it gets a
more natural looking height.
Change-Id: Idecbb3ee7b61fe55805d26cabdbaf1885574b3cf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170751
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
So lets implement this just by walking the document node structure.
I have tried to limit how much of the document this method now scans,
to avoid it also turning into an O(n^2) problem, but I might
have missed something, so
(a) the loop might be too conservative, in which case
performance could be better.
(b) the loop might not go far enough, in which case we might see
bugs with virtual page numbers.
This shaves 10% off the rendering time of large complex docx
documents.
Change-Id: I69711c65197caf278bd3ad2931c4817e72b28c5e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170451
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Not setting any parent window for XDocumentDigitalSignatures
causes the key selection window to be non-modal, letting the
user keep editing the document without completing the
encryption interaction.
Change-Id: Ic7e66cb43606355beaffc720b7c23cdf4f81d934
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170630
Tested-by: Jenkins
Reviewed-by: Sarper Akdemir <sarper.akdemir@allotropia.de>
This patch is the biggest logic change in this patchset:
- no notify if single property (!pNewChgSet) didn't cause a change
-bContinue can now be set false - avoiding a false notify
- multiple properties: don't block notify
-by doing this, I can remove my earlier fix.
------------------------------------------------
Here is my logic:
else if( pNewChgSet )
bContinue = false
simply was incorrect logic. There is no way we can say that
no notification is needed simply because one property is unchanged.
AT BEST (which will be done in a follow-up patch)
we will need to track how many bContinue = false's there are
and see if they match the number of properties that were passed.
But sufficient should be to only block when Count == 1,
like pOldChgSet now does.
bContinue = pNewChgSet->GetChgSet()->Count() > 1;
The variable pNewChgSet had been used earlier because it then
was checking if pNewChgSet->GetChgdSet...
But we can easily substitute pOldChgSet here, becoming
else if (pOldChgSet)
bContinue = pOldChgSet->GetChgSet()->Count() > 1;
There are three mutually exclusive code paths to consider:
pOldChgSet, bNewParent, or just a single property
Since bNewParent overrides bContinue elsewhere, ignore it
and it also doesn't make sense to continue for a single property,
so this could simply become
else
bContinue = pOld... && pOld...->GetChgSet()->Count() > 1;
which is identical to the bContinue in the if clause,
and thus they could be combined.
Change-Id: Ifa5ba56226f4e77a00f3bc8089a8dcaaca2b91ea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169898
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
I'm not sure when this started, but the testcase fails with:
- Expected: 6
- Actual : 7
I.e. the initial page count is meant to be more than 1, but we
explicitly assert that page count.
Once gb_CppunitTest_set_non_application_font_use is set to abort for
this suite, then vcl says the font fallback is:
vcl/unx/generic/fontmanager/fontconfig.cxx:1195: PrintFontManager::Substitute: missing font: 'Albany' try: Liberation Sans instead
Do that replacement, that restores the 6 pages on load even in cases
where it was 7 previously.
Change-Id: I0cf40c0cdbbb5c1e894468371ea260f0d15a3e40
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170759
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
