Create 2 new Writer documents in coda-m (so that they are both as tabs)
and close the first one. Collabora Office then crashes in
~FillBitmapLinkTracker:
#0 0x000000040c0705b4 in sw::FillBitmapLinkTracker::~FillBitmapLinkTracker at engine/sw/source/core/doc/FillBitmapLinkTracker.cxx:108
#1 0x000000040c070b14 in sw::FillBitmapLinkTracker::~FillBitmapLinkTracker at engine/sw/source/core/doc/FillBitmapLinkTracker.cxx:107
[... unique_ptr delete ...]
#6 0x000000040c06eb50 in sw::DocumentLinksAdministrationManager::~DocumentLinksAdministrationManager at engine/sw/source/core/doc/DocumentLinksAdministrationManager.cxx:436
#7 0x000000040c06ebbc in sw::DocumentLinksAdministrationManager::~DocumentLinksAdministrationManager at engine/sw/source/core/doc/DocumentLinksAdministrationManager.cxx:435
[... unique_ptr delete ...]
#12 0x000000040bfd0b50 in SwDoc::~SwDoc at engine/sw/source/core/doc/docnew.cxx:632
The tracker reached its LinkManager through the document:
m_rDoc.getIDocumentLinksAdministration().GetLinkManager()
SwDoc::getIDocumentLinksAdministration() returns
*m_pDocumentLinksAdministrationManager. On close the tracker is destroyed
while that manager is being destroyed: ~SwDoc destroys its
m_pDocumentLinksAdministrationManager member, and a unique_ptr clears its
stored pointer before it runs the deleter, so for the whole duration of
~DocumentLinksAdministrationManager (and the ~FillBitmapLinkTracker it
triggers) getIDocumentLinksAdministration() dereferences a null pointer.
The LinkManager it wanted is in fact still alive, it is just unreachable
through the half-destroyed document.
To fix this, hold the LinkManager directly.
Also includes a unit test, and I've tested it crashes without the change.
If it passes on other platforms, the problem might be platform-specific,
because the macOS libc++'s unique_ptr clears its stored pointer before
running the deleter, so the document was already unreachable during the
tracker's destruction.
This was introduced in d8a09afac610 (register writer XATTR_FILLBITMAP URLs
as SvBaseLinks via SwFormat and SwContentNode).
Signed-off-by: Jan Holesovsky <kendy@collabora.com>
Change-Id: I6fba231dde0b6b41f3af9c83208c7a2d5c7f0767
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/4131
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
(cherry picked from commit 96558fba2bc16d2245af1776a44c238bd60f4480)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208582
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
In a dbgutil build (on macOS - but probably does not matter), type a word in a
slide's text box, select it, copy it, move the cursor past it, and paste.
The paste asserts:
assert( IsUpdateLayout() && "Should not be used for Update=FALSE: GetTextHeight" );
The paste merges paragraphs, which reaches
EffectSequenceHelper::disposeTextRange through the ParagraphDeleted callback
(SdPage::onParagraphRemoving). To decide which effect to drop it called
isParagraphTargetTextEmpty(), which reads the shape text through the UNO text
forwarder and so forces a text frame layout recompute
(NbcAdjustTextFrameWidthAndHeight, then GetTextHeight). The paste runs with
the EditEngine layout updates suspended, hence the assert in
ImpEditEngine::GetTextHeight.
Decide the previous paragraph's emptiness in onParagraphRemoving, where the
editing outliner with the live text is at hand, and pass it down to
disposeTextRange. This drops the UNO read and its layout side effect for
every case, animated or not.
Includes a unit test that executes the sequence described at the beginning;
without the fix, it fails with an assert.
Signed-off-by: Jan Holesovsky <kendy@collabora.com>
Change-Id: Id6ae3c8a121f036f87fa43ce134541376ff0b179
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/3669
Reviewed-by: Noel Grandin <noel.grandin@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 89a1a74dc95054698c1097b0aea0466ad6a6e092)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206213
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
LOKit will need to run in the sandbox in the end, and this avoids a
crash in coolwsd, so let's configure with this right away.
Change-Id: Iac58b20192274fea749befd8bb77592852edb64c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/197208
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@iki.fi>
So disable it from the configure & make sure it is not brought in by the
non-iOS check.
Change-Id: I9bbf1c593d1d48197951002e04e7f925d35ecba9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146034
Tested-by: Jenkins
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
We have a "GraphicCrop" property that is supposed to roundtrip the
cropping in OOXML, but there is no core feature backing it (ie. the
image is not shown cropped when this is imported and set).
Instead, to show the image "cropped", we crop the image physically on
import (throw away pixels that are 'outside' of the cropped area).
But - the "GraphicCrop" is then saved on export, together with the image
already physically cropped, which leads to garbled DOCX on re-import.
Given that the core feature to show image cropped when the "GraphicCrop"
is set, let's avoid setting it when we physically crop the image.
Change-Id: Ia1090ea9c6d22e60c77d52bf65281f6588d07d4e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143216
Tested-by: Jenkins
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
When editing was introduced in Calc LibreOfficeKit, there were lots of
limitations. Particularly the thinking was that it would be good if a
double-click into any text (even if spanning over more cells)
actually started editing that text.
These days, the LOK behaves much more consistently, so it is better to
behave as the LibreOffice on desktop (or other tools, like gdocs) do:
If the cell:
* Is empty
-> single click places the cell cursor
-> double click places the cell cursor & shows the text caret
* Is empty, but covered by text bleeding from other cell
-> same as if it was empty
* Isn't empty
-> single click places the cell cursor
-> double click places the cell cursor & places the text caret
inside the text where the user clicked
+ this is actually different in gdocs - there the caret is
placed at the end of the text; in LO it is where the user has
double-clicked
Change-Id: Ib5884f887c98f803b06d8bed5057ec435be480ef
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142196
Tested-by: Jenkins
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
Without this, when the user tries to open a 0-bytes .txt file, they are
asked for a Save As operation after they hit the Save button.
When we remove the 'txt' from the T602 detection, it rather asks if the
user wants to use ODT or Plain text (and lose formatting).
Change-Id: Ic48fa61064a9ed78c64d56bc8864f0e12528e072
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123216
Tested-by: Jenkins
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
This partially reverts "lok: sc - suppress LOK editengine events for the calc input bar."
The feature itself is very problematic in Online:
1) causes unwanted jumps to other cells,
2) causes the selection blinking in the cell when typing, and
3) it is very annoying in the form that in which it is implemented
in LibreOffice anyway, compared to other office suites.
Let's disable it, and enable again when we address the above issues.
This (partially) reverts commit 91319ad56887f932b2da334db560d5d0a79a0280.
Change-Id: I2234455c29069f74d13896474f3499035935931b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113047
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
(cherry picked from commit 65990058f041c3f1d280a69d411eb4ceacf5a721)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113112
Tested-by: Jenkins
The test was supposed to test whether the PNG data is embedded (or not),
not the actual content of the data. Turns out that a different zlib
affects the PNG content, so let's ignore that part, and only check that
the data is actually embedded.
Change-Id: I603bd546d97abda7c47248db0a95349f4a48b4aa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101329
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Unfortunately we need this on Android for the tablets, otherwise the
sidebar lacks the icons.
Also it is not easily possible to use the isLOKMobilePhone() check here,
because that is per-view in general, and handled in sfx in particular,
making it hard to use here in vcl.
This reverts commit 9a38b194eec5bcf6cb8d073e5d35173c5856f28f.
Change-Id: I2b599e884ad4d00b7c246743c180a5324c9a143d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99300
Tested-by: Jenkins
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Without this, zh-Hant-TW locale used via the LibreOfficeKit was reduced
to zh-Hant and further to zh, which was interpreted as zh-CN, causing
incorrect strings particularly in the sidebar.
Change-Id: I58e53f71d13824e422a7b3634f3822d55090f8ee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99203
Tested-by: Jenkins
Reviewed-by: Andras Timar <andras.timar@collabora.com>
The "LOK: emit modified status on entering cell data" patch did this
only for the formula input line, and did not change the state when the
user just clicked on the cell and started modifying it; so this patch
extends it.
Also change the actual DocumentModified state of the document directly
instead of just sending a flag, so that the state in LOOLWSD and in the
core don't get out of sync.
Change-Id: Ie516ce5a74d94247d79cf993517d7f4a6657cc94
Reviewed-on: https://gerrit.libreoffice.org/75701
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95516
Tested-by: Jenkins
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
In principle, the current Svg/Emf/Wmf and PDF handling is trying to
achieve the same thing: Keep the original stream untouched, provide a
replacement graphics, and a kind of rendering.
To hold the data, the Svg/Emf/Wmf and PDF were using different structures
though. This commit consolidatates that, and makes the Insert
-> Image... (for PDF) actually using the VectorGraphicData to hold the
original stream.
This breaks loading the PDF as a document via PDFium - I'll fix it in
the next commit(s).
Change-Id: Iac102f32b757390a03438c165e430283851cc10b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90561
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
From some reason it fails to be read from the versionrc; and I'm not
really eager to debug why...
Without this, only the dictionaries that do not mention the
OpenOffice.org-minimal-version are registered; which would be just 2 of
them.
Change-Id: I9fe0bc138eadbdcbe5e0d8231e7e90ef268163bc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88219
Tested-by: Jan Holesovsky <kendy@collabora.com>
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88366
Tested-by: Jenkins
...and try to register it for use - it's a bundled extension.
The attempt to use the Android's native spell checking failed because
the combination of gboard + google's spell checker makes every word in
the app appear as if spelled correctly.
I haven't found any easy way around that, so let's use hunspell instead;
but for that, we need to make the bundled extensions work on Android.
Change-Id: If6563e497f1d3085c26eda571567242b2c1f6181
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88217
Tested-by: Jan Holesovsky <kendy@collabora.com>
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88364
Tested-by: Jenkins
But OTOH in the preload case, the libraries we'd otherwise load are not
there.
An example was libcuilo.so where the instantiation of the spell checking
dialog was failing, because it was impossible to find the
makeSentenceEditWindow symbol.
Change-Id: Ifc0bc5d8b295912728505fe3ce11fa4a0d198124
Reviewed-on: https://gerrit.libreoffice.org/80229
Tested-by: Jenkins
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
Otherwise it is not found when the the fontconfig's ./configure is
running, which leads to linking failure during the fontconfig's
./configure time, which leads to an undefined HAVE_FT_GET_NEXT_CHAR
which leads to not using the actual FT_Get_Next_Char, but instead some
dummy code that leads to an infinite loop on the app startup; huh.
Change-Id: I40b7a403fbe75582bb98f15f1afe7a4050fd13aa
Reviewed-on: https://gerrit.libreoffice.org/83922
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
Tested-by: Jan Holesovsky <kendy@collabora.com>
(cherry picked from commit 94eb59078731b2e4093d983bc618d051f4e31740)
Reviewed-on: https://gerrit.libreoffice.org/84190
Tested-by: Jenkins
No need for this when we have a compile-time distinction now anyway.
Change-Id: Ic86c8cce38a86635ea3efb4229c08f63059c9ee6
Reviewed-on: https://gerrit.libreoffice.org/83719
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
Tested-by: Jenkins
Forces gold as the linker; but according to the switches that were used,
I suppose gold was used previously anyway, so hopefully not really a
problem.
Change-Id: I7bc54abf0d3b4b3d86d53e4ea6f01146cf196216
Reviewed-on: https://gerrit.libreoffice.org/81905
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
Tested-by: Jan Holesovsky <kendy@collabora.com>
(cherry picked from commit fa145a035fbab652ec8f3ee870e44e43dd1d770a)
Reviewed-on: https://gerrit.libreoffice.org/81915
This indicates that the build targets the Online-based Android app, for
which we need to avoid various tweaks that are needed for the 'old'
Android app present in the android/ subdir of core.git.
In particular, the switch used in this patch fixes a RGBA vs. BGRA
confusion that caused yellow <-> cyan switch in the Online-based Android
app.
Change-Id: I5f394868f51ce87013677834cfafb967b9bb333e
Reviewed-on: https://gerrit.libreoffice.org/83342
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
(cherry picked from commit 49002a143a4534df5f6139e07fefd06174621c59)
Reviewed-on: https://gerrit.libreoffice.org/83718
Tested-by: Jenkins
Without this, we get a linking error that RID_PAGEFORMATPANEL_MARGINS_CM
is defined twice.
Change-Id: Ib9c07adcb0a8def991d1e39429c1bb4947cd7d32
Reviewed-on: https://gerrit.libreoffice.org/82159
Tested-by: Jenkins
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
This partially reverts a7f6338875. The
problem is that with that approach, the problems with unwinding as
described in 312eeeee42 were plaguing the
Online-based Android app, leading to mysterious crashes with stack
traces like:
#00 pc 0005f2b6 /apex/com.android.runtime/lib/bionic/libc.so (abort+166) (BuildId: 68c87e04526a60689ecb5deb329804a0)
#01 pc 05caaae7 /data/app/libreoffice.debug-fBEOIUwPHY3_k3eQid159Q==/lib/arm/liblo-native-code.so (BuildId: 1c3d0e6336ddfc3578e1c186944160252a750b8b)
...
#06 pc 07452e43 /data/app/libreoffice.debug-fBEOIUwPHY3_k3eQid159Q==/lib/arm/liblo-native-code.so (BuildId: 1c3d0e6336ddfc3578e1c186944160252a750b8b)
#07 pc 0005a37c /apex/com.android.runtime/lib/bionic/libc.so (__restore_rt) (BuildId: 68c87e04526a60689ecb5deb329804a0)
#08 pc 0005f2b2 /apex/com.android.runtime/lib/bionic/libc.so (abort+162) (BuildId: 68c87e04526a60689ecb5deb329804a0)
#09 pc 07565d3b /data/app/libreoffice.debug-fBEOIUwPHY3_k3eQid159Q==/lib/arm/liblo-native-code.so (BuildId: 1c3d0e6336ddfc3578e1c186944160252a750b8b)
...
#11 pc 07565641 /data/app/libreoffice.debug-fBEOIUwPHY3_k3eQid159Q==/lib/arm/liblo-native-code.so (BuildId: 1c3d0e6336ddfc3578e1c186944160252a750b8b)
#12 pc 0001e394 /apex/com.android.runtime/lib/bionic/libm.so (__gnu_Unwind_RaiseException+108) (BuildId: 0ee3a75927e0da4fa0fe29469ccf8b39)
#13 pc 0001eee8 /apex/com.android.runtime/lib/bionic/libm.so (_Unwind_RaiseException+20) (BuildId: 0ee3a75927e0da4fa0fe29469ccf8b39)
Change-Id: Ie4e7b20380c9104770229a8d30036ad76093283d
Reviewed-on: https://gerrit.libreoffice.org/81485
Tested-by: Jenkins
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
Just specify:
--with-android-ndk=$HOME/Android/Sdk/ndk-bundle
--with-android-sdk=$HOME/Android/Sdk
in your autogen.input, install the appropriate components via Android
Studio and you are done.
Change-Id: Ic99790b781b9017eb4e642380e230d6f7b49e9b7
Reviewed-on: https://gerrit.libreoffice.org/81228
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
(cherry picked from commit 246f1b5b4485b7db9f9584e4b3b819c87e331c0e)
Reviewed-on: https://gerrit.libreoffice.org/81328
Tested-by: Jenkins
Turns out that this is still a condition that can happen regularly:
* open Impress
* click an object with a spelling mistake
* press F7 to activate the spelling dialog (don't choose it from the
menu)
=> assert()
It is unclear how to sort this out correctly without refactoring, and
also unclear how many other cases fail this condition, so let's change
to SAL_WARN_IF for the moment.
Change-Id: I97730cc93c86c279973702bbf4ddc922f1616c0b
Reviewed-on: https://gerrit.libreoffice.org/80170
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Before this patch, copy in Calc, Paste in Writer produced an embedded
sheet. I suspect is it not what the people usually want; working with
the embedded sheets in Writer is non-intuitive, I suspect people will be
happier with a normal table which they can style etc. appropriately.
OTOH - this is a general change, so it might have some unwanted
side-effects; let's see what if we get bugreports :-)
tdf#127673 was related; but in my view, we shouldn't create the embedded
objects in the first place.
Change-Id: I73710168d8924fdd6275d65e20cf55f38971a3f9
Reviewed-on: https://gerrit.libreoffice.org/79606
Tested-by: Jenkins
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
There are all sorts of problems when we'd try to edit the embedded
objects, like that that LOK thinks it is a separate view etc., so better
to disable it for now, before we really need to edit embedded objects.
Change-Id: Ie8c0249cb0ca8b25a2ac97c1ccec4a5a62cbb770
Reviewed-on: https://gerrit.libreoffice.org/79555
Tested-by: Jenkins
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
Turns out that it is confusing for the users that they can edit the
properties of the chart rather than its position just after inserting
it in the browser.
Let's change it accordingly. When the user wants to edit the chart
itself, they have to double-click.
Calc is not handled in this patch.
Change-Id: If5661b843a06ebaeb8d4cd1b2c469aeedda4257e
Reviewed-on: https://gerrit.libreoffice.org/78318
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
This fixes the destruction of the static cache of the PDF data; without
this, there were already missing uno runtime info.
(cherry picked from commit 20055ebe1b27f716a2acf1f0f4dda2864ae811bf)
Change-Id: I877c9ccf96c4b7eabf3d643e17f324d86d987f94
Reviewed-on: https://gerrit.libreoffice.org/77691
Tested-by: Jenkins
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
If we swap out too early, the constructor of GraphicObject forces a swap
in, so we'd render everything during the load anyway.
Change-Id: I0ea1a755242fd57ef28d082ce4bf534a32199f87
Reviewed-on: https://gerrit.libreoffice.org/56286
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
(cherry picked from commit 242c7663e275a712430a8c4ac8eeacbb8b3bd440)
Reviewed-on: https://gerrit.libreoffice.org/77690
Tested-by: Jenkins
Otherwise we get crashes in online Kit when attempting to shutdown
reasonably cleanly and the poll kicks in.
Change-Id: I9a1744b42fec9f8ffddc6094773bda943caedf2a
Reviewed-on: https://gerrit.libreoffice.org/74064
Tested-by: Jenkins
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
In the desktop version, the value that is entered there always ends up
applied. In the Online, there was a scenario when it did not: enter a
value and switch slide by clicking the slide sorter.
There is no harm to apply the value right away when the user edits,
because in the desktop version, there was no way to avoid applying the
value anyway.
Change-Id: I519423d60f682735aeb1d471b3397ff9671c15fd
Reviewed-on: https://gerrit.libreoffice.org/72924
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
Tested-by: Jenkins
Without this, the vcl's AboutDialog conflicts with the AboutDialog from
cui during linking of liblo-native-code.so.
Change-Id: Ie6e5ddd52bb7bdee1c7d53c37ea566d7ce6c9385
Reviewed-on: https://gerrit.libreoffice.org/73613
Tested-by: Jenkins
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
This is useful for the Online, where we want to insert the text box
directly into the document so that it is visible right away.
Change-Id: I09ab2efba758aac077fa37ddfd20b1486b35b3ef
Reviewed-on: https://gerrit.libreoffice.org/72912
Tested-by: Jenkins
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
Jan Holesovsky