[upstream] Loop in libreoffice-calc when scrolling to top of spreadsheet

[Cliff Carson]

Have a spreadsheet used in many past release of calc that is now failing. When opening this sheet and if not currently at the top of the sheet using the mouse wheel to move to the top (top line to the top of the window) soffice.bin goes to 100% cpu and stays there. Can't use the mouse wheel to move off of the top line. Can move off the top line by using the mouse and scroll bar. As soon as you are off the top line the loop in soffice.bin stops. This is the only sheet I can find that fails but it does fail on this laptop and also my desktop which is also running Ubuntu 19.10/libreoffice-calc-6.3.2.2. Adding failing spreadsheet file to this bug report.

ProblemType: Bug
DistroRelease: Ubuntu 19.10
Package: libreoffice-calc 1:6.3.2-0ubuntu2
ProcVersionSignature: Ubuntu 5.3.0-13.14-generic 5.3.0
Uname: Linux 5.3.0-13-generic x86_64
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair nvidia_modeset nvidia
ApportVersion: 2.20.11-0ubuntu7
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Sun Oct 6 06:35:42 2019
InstallationDate: Installed on 2019-10-03 (2 days ago)
InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Beta amd64 (20191001.2)
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: libreoffice
UpgradeStatus: No upgrade log present (probably fresh install)

[Raal (raal)]

Description:
button flashing

Steps to Reproduce:
Open file from bug 121919 https://bugs.documentfoundation.org/attachment.cgi?id=147324
Sheet Session Scores, see button "Calculate Scores"

Actual Results:

actual result
text is blinking /button flashing
If the problem is not visible Zoom in

Expected Results:
button without movement

Reproducible: Always

User Profile Reset: No

Additional Info:

[Raal (raal)]

This seems to have begun at the below commit.
Adding Cc: to Armin Le Grand ; Could you possibly take a look at this one?
Thanks

8a7827fc2caad9893cd7583be164ca5cd115a999 is the first bad commit
commit 8a7827fc2caad9893cd7583be164ca5cd115a999
Author: Jenkins Build User <email address hidden>
Date: Thu Nov 29 00:31:25 2018 +0100

    source sha:d464d505fbf6e53a38afdd3661d320fac8c760d6
author Armin Le Grand <email address hidden> 2018-10-12 11:13:09 +0200
committer Armin Le Grand <email address hidden> 2018-11-27 11:33:10 +0100
commit d464d505fbf6e53a38afdd3661d320fac8c760d6 (patch)
tree 3bf7db8591172bf948198f19d36df5df886486bb
parent 3e1e2b6687b0259ae28441cc0d314de0d908776b (diff)
Refactor calc non-linear ViewToDevice transform

Tested on windows and Linux

[Raal (raal)]

*** Bug 122083 has been marked as a duplicate of this bug. ***

[Xiscofauli (xiscofauli)]

I do reporudce it if I zoom in

Version: 6.3.0.0.alpha0+
Build ID: 1b7bcaa714f0af45c6a9660d1f0940cb7931ba0f
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3;
Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US
Calc: threaded

[Xiscofauli (xiscofauli)]

*** Bug 122644 has been marked as a duplicate of this bug. ***

[Libreoffice-z (libreoffice-z)]

REPRODUCIBLE with Version: 6.3.0.0.alpha0+
Build ID: 2e3b0c5d42d60d46cd9f8b8eda9424b095c63418; Windows 6.1
and own sample document with form controls

[Xiscofauli (xiscofauli)]

The mentioned commit also breaks the mouse wheel zooming if there is a button on the spreadsheet. Increasing severity towards 6.3 release

[Oliver-brinzing (oliver-brinzing)]

*** Bug 126558 has been marked as a duplicate of this bug. ***

[Oliver-brinzing (oliver-brinzing)]

this issue is reproducible with release:

Version: 6.3.0.4 (x64)
Build-ID: 057fc023c990d676a43019934386b85b21a9ee99
CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; VCL: win;
Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE
Calc:

[Oliver-brinzing (oliver-brinzing)]

*** Bug 126778 has been marked as a duplicate of this bug. ***

[Xiscofauli (xiscofauli)]

*** Bug 126845 has been marked as a duplicate of this bug. ***

[JBF (jbf-faure)]

*** Bug 126987 has been marked as a duplicate of this bug. ***

[JBF (jbf-faure)]

In addition to the button flickering, we have 100% CPU consumption.

Tested in Version: 6.3.2.0.0+
Build ID: 97b6565f27acad7288de016530c753f27f9d55f9
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3;
Ubuntu_18.04_x86-64
Locale: fr-FR (fr_FR.UTF-8); UI-Language: en-US
Calc: threaded

Best regards. JBF

[Oliver-brinzing (oliver-brinzing)]

*** Bug 127155 has been marked as a duplicate of this bug. ***

[Xiscofauli (xiscofauli)]

*** Bug 127352 has been marked as a duplicate of this bug. ***

[Jaise (jaise)]

In calc Side bar, cell appearance - > cell border line style[ on adding any cell border enable it] flickering continuously.

[Oliver-brinzing (oliver-brinzing)]

*** Bug 127444 has been marked as a duplicate of this bug. ***

[Aron Budea (baron-z)]

*** Bug 127503 has been marked as a duplicate of this bug. ***

[Oliver-brinzing (oliver-brinzing)]

*** Bug 127563 has been marked as a duplicate of this bug. ***

[Xiscofauli (xiscofauli)]

*** Bug 127067 has been marked as a duplicate of this bug. ***

[Oliver-brinzing (oliver-brinzing)]

*** Bug 127636 has been marked as a duplicate of this bug. ***

[Xiscofauli (xiscofauli)]

*** Bug 127828 has been marked as a duplicate of this bug. ***

[2-office (2-office)]

Is there any (alpha, daily) version that has some kind of fix for this Bug to test if it's working. I would test it asap ;-)

[Xiscofauli (xiscofauli)]

*** Bug 127842 has been marked as a duplicate of this bug. ***

[Burnuser (burnuser)]

LO 6.3.2.2 German on Win 10 x64:
a) flickering Form-Button
b) flickering colors in color palette while moving mouse over colors
c) flickering in selection drop down - Line style/width (Calc cells + graphic elements)

+ CPU = 30% while doing nothing!

[Cliff Carson (ccarson1)]

Found an additional spreadsheets that fail. Appears to be associated with a user defined button/macro. In the TheGrid sheet the button/macro is placed near the top of the sheet so the failure occurs when I scroll to the top of the sheet. In the case of another sheet the button/macro os down several rows from the top of the sheet. When I open this second sheet and the button/macro is displayed I get the soffice.bin loop. Using the scroll bar and scrolling the button/macro up off of the displayed area the loop stops and the mouse wheel works again. Using the mouse wheel or scroll bar to move the sheet so that the button/macro is displayed the loop returns and the wheel stops functioning.

[Xiscofauli (xiscofauli)]

*** Bug 128093 has been marked as a duplicate of this bug. ***

[Tim Passingham (tim-8aw3u04umo)]

If only I had search for 'flicker', instead of 'shake' or 'vibrate', I wouldn't have raised a duplicate. Sorry.

But it is still a current issue on:
Version: 6.3.2.2
Build ID: 1:6.3.2-0ubuntu0.19.04.1~lo1
CPU threads: 8; OS: Linux 5.0; UI render: default; VCL: x11;
Locale: en-GB (en_GB.UTF-8); UI-Language: en-GB
Calc: threaded

[Stevepattinson (stevepattinson)]

Simple Questions / Feedback / Observations (please don't take offence):

* You have a stable version (6.2), so what is the purpose of something like the 6.3 version, with multiple releases. I can understand alpha/beta versions being available whilst bugs/design issues are being addressed, but when you remove those statuses and give it what appears to be a "released" version nomenclature, then user expectation changes accordingly.

* This problem, which at first sight seems to be quite serious for those afflicted by it, has been identified around 10 months ago. Given the previous point, not having any feedback regarding ETA (or even if it is being looked at) is disturbing. As I said, purely from a user's perspective, ver 6.3 looks like a production version of LO. And therefore, I would also have an expectation about having to revert as a result of inactivity, losing as a result, the slew of excellent enhancements present in 6.3

regards, Steve

[Marcus Tomlinson (marcustomlinson)]

Hi Cliff, thank you for taking the time to write this detailed report. Evidently this is not an Ubuntu-specific issue - I've managed to reproduce this on Debian Stretch with TDF's own 6.3.2 deb (https://www.libreoffice.org/download/download/?type=deb-x86_64).

Could I please ask you to file an upstream bug for this at https://bugs.documentfoundation.org/enter_bug.cgi?product=LibreOffice&format=guided and share the link to that bug here?

Thank you again!

[Iretire2002 (iretire2002)]

Created attachment 155016
Spread sheet with button/macro defined

When scrolling with mouse wheel loop in soffice.bin occurs when a button/macro is scrolled onto the visible area. Mouse wheel stops responding. Can scroll off the button/macro by using the scroll bar. Once the button/macro is off visible area the loop stops. This was submitted initially under Ubuntu bug 1846940. Attached is a failing spreadsheet.

[Cliff Carson (ccarson1)]

Created Bugzilla bug report 128151 per request.

[J-ragan (j-ragan)]

I have narrowed it down to the following:
If a form has more than one control and in the underlying sheet column width in any one column is set to different than default, then all controls on the form start (not always immediately) to refresh (redraw) in a continuous loop affecting overall performance.

Steps to reproduce the bug:
1.Create new sheet
2.Add two controls to the form
3.Resize a few columns on the sheet

If all columns have default width this bug will not manifest itself.
If there is one control on the form, this bug will not manifest itself.

Reproducibility is a bit sketchy, since sometimes it starts to continuously refresh immediately and sometimes it takes a few seconds to catch on.

[Oliver-brinzing (oliver-brinzing)]

*** Bug 128147 has been marked as a duplicate of this bug. ***

[Oliver-brinzing (oliver-brinzing)]

after opening attached spreadsheet document, the button "update" on sheet "Grid2" flickers, scrolliing down stops flickering as soon as button is no longer visible.

flickering will also stop if i set column F to optimal width.

this issue seems also be a duplicate of:

Bug 121963 - button flashing - mouse wheel zooming breaks

*** This bug has been marked as a duplicate of bug 121963 ***

[Oliver-brinzing (oliver-brinzing)]

*** Bug 128151 has been marked as a duplicate of this bug. ***

[Oliver-brinzing (oliver-brinzing)]

(In reply to Julian Ragan from comment #28)
> If all columns have default width this bug will not manifest itself.

confirming, root cause seems to be the column width.

please have a look at:
https://bugs.documentfoundation.org/show_bug.cgi?id=128151#c1

[Marcus Tomlinson (marcustomlinson)]

Synchronising bug status with upstream.

[Xiscofauli (xiscofauli)]

*** Bug 128326 has been marked as a duplicate of this bug. ***

[Ethomasma (ethomasma)]

(In reply to Julian Ragan from comment #28)
> I have narrowed it down to the following:
> If a form has more than one control and in the underlying sheet column width
> in any one column is set to different than default, then all controls on the
> form start (not always immediately) to refresh (redraw) in a continuous loop
> affecting overall performance.
>
> Steps to reproduce the bug:
> 1.Create new sheet
> 2.Add two controls to the form
> 3.Resize a few columns on the sheet
>
> If all columns have default width this bug will not manifest itself.
> If there is one control on the form, this bug will not manifest itself.
>
> Reproducibility is a bit sketchy, since sometimes it starts to continuously
> refresh immediately and sometimes it takes a few seconds to catch on.

I have CALC workbook with only 1 control. It flickers so issue does occur with just 1 control

[Xiscofauli (xiscofauli)]

*** Bug 128107 has been marked as a duplicate of this bug. ***

[J-ragan (j-ragan)]

(In reply to Elizabeth Thomasma from comment #33)

> I have CALC workbook with only 1 control. It flickers so issue does occur
> with just 1 control

I can't reproduce it (in files created from scratch at least), without using zoom functionality (which I don't use in my workflow).
One control on a page with default zoom and non-default column width does not trigger this bug for me.
Two or more controls and non default column width - it starts flashing after loading file, or if file is newly created, then it randomly takes up to few seconds.

However, with single control I can only reproduce the bug with the use of zoom feature.
Reproduction:
1. Create new file
2. Add one control
3. Resize one column (necessary, could not reproduce without this step)
4. Zoom out to at least 80% or zoom in to at least 110% (those values appear to be trigger points for this bug for forms with one control on them)

Can you check if you have non default zoom in your file and if yes, then check what happens with your file if you set zoom to 100%?

[J-ragan (j-ragan)]

While further testing zoom functionality I was able to once trigger this bug on a new file with default column width and one control.

However, I was not able to reproduce with multiple attempts.

[Xiscofauli (xiscofauli)]

*** Bug 128368 has been marked as a duplicate of this bug. ***

[Devseppala (devseppala)]

I believe that I have also stumbled on this bug and it seems to be very cumbersome to trigger.

In my experience this bug triggered more by non-uniform row height than column width. Can anyone else trigger this bug with uniform column width and non-uniform row height?

Also in my case, forcing uniform row height does fix this issue. Even if you change the height of some row afterwards. But it is only fixed for the current zoom level. If you change the zoom level, the flickering will come back on some other zoom level. Now the bug just manifests itself on a different zoom level than previously.

Also, in some situations all of the menus and dialogs show up empty, while this bug is active.

On multiple occasions, I have been able to trigger this with just one form control, but for some reason I can not find a pattern that would work always. With two controls it is more consistent, but with two controls I have not experienced the disappearing of menus and dialogs.

[Devseppala (devseppala)]

Adding to previous that if you enable:
“Options > LibreOffice > View > Use OpenGL for all rendering”

There is no flickering, but menus and dialogs show up empty. CPU use is high and GPU is 98%.

[julien2412 (serval2412-6)]

Created attachment 155290
perf flamegraph

On pc Debian x86-64 with master sources updated 2 days ago, I retrieved a Flamegraph.

Perhaps it may help.

[julien2412 (serval2412-6)]

Adding traces in some functions of the quoted commit, I noticed this block was repeted infinitely:
OverlayObject::getOverlayObjectPrimitive2DSequence
OverlayObject::getOverlayObjectPrimitive2DSequence
ViewObjectContact::getPrimitive2DSequence
ViewObjectContact::getGridOffset
ViewObjectContact::getPrimitive2DSequence
ViewObjectContact::getGridOffset
ViewObjectContact::getPrimitive2DSequence
ViewObjectContact::getGridOffset

[Devseppala (devseppala)]

When I searched the originating commit from Github:

https://github.com/LibreOffice/core/search?q=d464d505fbf6e53a38afdd3661d320fac8c760d6&type=Commits

I noticed that developer vmiklos had fixed a similar issue as this bug:

tdf#123505 svx: fix invalidation loop caused by special form control …
https://github.com/LibreOffice/core/commit/5b51aa12e8ebfa894ecfdd0c8c9004aa99e6f46d

Is there some way to ask if he could look in to this issue too. It seems very similar to the one he already worked on and is related to the same originating commit.

[Xiscofauli (xiscofauli)]

*** Bug 122713 has been marked as a duplicate of this bug. ***

[Xiscofauli (xiscofauli)]

*** Bug 125720 has been marked as a duplicate of this bug. ***

[Armin-le-grand (armin-le-grand)]

Happens when the Control is live (not edit mode) and the mapping is - due to non-linear ViewMapping in Calc - dependent on pixel sies. In these cases, ViewObjectContactOfUnoControl_Impl::positionAndZoomControl is called. That uses adjustControlGeometry_throw where

aTopLeft, aBottomRight change while
_rLogicBoundingRect does not (mostly flicker of a single pixel).

This is due to different _rViewTransformation being used, dependent on where the paint is compng from (yes, the live Controls' positioning works by lay-positioning these during paint what may lead to an invalidate in the window, but usually only *once*, except for the crude Calc non-linear ViewTransform mapping - ARGH)

Key to fix this will be to find out which tranform would be the correct one and which path uses the wrong one...

All calls emerge from a single ScGridWindow::DrawContent. Every 2nd paint triggers between two pixel value variations, this can be best seen in

ControlHolder::setPosSize

One call inside ScGridWindow::DrawContent triggers one pixel value set, another triggers the alternative one. These calls are:

    DrawRedraw( aOutputData, SC_LAYER_INTERN ); -> smaller/more left
            pContentDev->SetMapMode(aCurrentMapMode); -> bigger, more right

These do then alternate endlessly, because they invalidate different parts. Question is why these lead to different pixel position values...

[Liste-o (liste-o)]

I think that's I have de same problem with this version :

Version: 6.4.0.0.alpha1
Build ID: cc57df8f942f239d29cb575ea5a7cb01405db787
Threads CPU : 4; OS : Linux 5.3; UI Render : par défaut; VCL: gtk3;
Locale : fr-FR (fr_FR.UTF-8); Langue IHM : fr-FR
Calc: threaded

I can use LibO 6.3 because the CPU up to 100% when I use my sheet with macro. LibO 6.4 have the same problem.

The file Xray have this problem.

[Armin-le-grand (armin-le-grand)]

In adjustControlGeometry_throw aViewTranslate is sometimes *not* zero, but has some values. Thi seems to be the reason for the offsets - tried to hunt down where this comes from, but hard to find - about 25 stack levels involved...

[Armin-le-grand (armin-le-grand)]

Seems to be special stuff with controls - sigh.
When breaking in svx\source\sdr\contact\objectcontactofpageview.cxx:290 in line

                    pProcessor2D->process(xPrimitiveSequence);

it can be seen that the ViewInformation2D from *this and at the processor is the same, while later in LazyControlCreationPrimitive2D::get2DDecomposition it is *different*.
This is because the processed SeqOfPrim modifies it - in VclProcessor2D::RenderTransformPrimitive2D. This means the ControlPrimitive itself contains the offset (in my local example '30' which leads to a pixel offset of 1.0889). Forcing this to zero silences the repaint.

Thus the question is: Who and why does someone create a TransformPrimitive2D? There are probably good reasons, so maybe we get a principal problem here...?

[Armin-le-grand (armin-le-grand)]

The embedding to TransformPrimitive2D is indeed created by ViewObjectContact::getPrimitive2DSequence and taking supportsGridOffsets/getGridOffset into account - what is completely corect and core element of the change.
What seems wrong OTOH is more that in ViewObjectContactOfUnoControl_Impl::positionAndZoomControl the GridOffst is *not* taken into account -> need to add that.
Made a 1st rough try in adding to _rViewTransformation, but this would add it double in the non-EndRepaint stuff. Thus the logically correct thing to do is probably to not use

                const tools::Rectangle aRect( pUnoObject->GetLogicRect() );

in ViewObjectContactOfUnoControl_Impl::positionAndZoomControl, but to get the B2DRange from the SeqOfPrim which will then correctly include the offset...

[Armin-le-grand (armin-le-grand)]

Problem is that ViewObjectContactOfUnoControl_Impl::positionAndZoomControl is used in two scenarios:
(1) During paint -> GridOffset is already part of ViewTransformation2D
(2) Other (IsVisible, getPrimSeq, ...) -> GridOffset *not* added
while (1) is coming from LazyControlCreationPrimitive2D::get2DDecomposition while (2) comes from ViewObjectContactOfUnoControl::isPrimitiveVisible.

Using m_pAntiImpl->getObjectRange() in ViewObjectContactOfUnoControl_Impl::positionAndZoomControl in both cases will not work -> in case (1) the GridOffset will be taken into account *twice*. So there are two alternatives:

(a) extend ViewObjectContactOfUnoControl_Impl::positionAndZoomControl with a flag to internally know if GridOffset is alread added
(b) add GridOffset for all usages of (2) to ViewTransformation2D

Not sure what is better, have to think about it strategically/from the underlying principle...

[Devseppala (devseppala)]

Very interesting to read about your bug hunt Armin, and good to see that you have made so much progress.

About your A/B solution options. Is there any performance issue to consider, how often are these called in worst case scenario. I mean checking a flag sounds potentially more slower than just systematically adding the offset.

Just my 2 cents, great work!

[Armin-le-grand (armin-le-grand)]

@devseppala: Well - the GridOffset needs to be applied in both cases, so this makes not really a difference...

From the logic I think (2) is the better option - will now do that and check if it works as intended. Keep in mind that the GridOffset stuff itself is a compromize fix for the (hard) calc probem of non-linear ViewTransformation(s) for pixel-oriented displays - I know that since I implemented it ;-)
In the long run a view-dependent solution using VOC/OC/VC in combination with primitives would be much better anyways... but thats another story ;-)

[Armin-le-grand (armin-le-grand)]

Works well, but need to update local master 1st to prepare commit ...

[Armin-le-grand (armin-le-grand)]

Proposed fix at https://gerrit.libreoffice.org/#/c/82031/

[Libreoffice-commits (libreoffice-commits)]

Armin Le Grand committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/fd2174d55dadc3b4dcf6b15b5789077bb2951698

tdf#121963 apply GridOffset in isPrimitiveVisible

It will be available in 6.4.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

[Armin-le-grand (armin-le-grand)]

Okay, comitted and checked by Xisco

[Xiscofauli (xiscofauli)]

Verified in

Version: 6.4.0.0.alpha1+
Build ID: ee909ca2c02f949605f68720c3f1eef658502749
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: x11;
Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US
Calc: threaded

@Armin, thanks for fixing this issue!!

[Devseppala (devseppala)]

I tested today's build:
https://dev-builds.libreoffice.org/daily/master/Win-x86_64@tb77-TDF/2019-11-05_05.07.09/LibreOfficeDev_6.4.0.0.alpha1_Win_x64.msi

and the fix works also for me.

Could this fix be included in the 6.3.x series too. I would consider this as quite important bug fix, and from the amount of duplicate bugs, it seems to have affected quite a few. In addition, the fix seems to be quite unintrusive and it fixes a regression introduced in this series.

[J-ragan (j-ragan)]

I confirm fixed on

Wersja: 6.4.0.0.alpha1+ (x64)
Build ID: 16dd2d153475265e9bdf9b8e736dca0b7b5b20f9
Wątki CPU: 8; OS:Windows 6.1 Service Pack 1 Build 7601; UI render:domyślny; VCL: win;
Ustawienia regionalne: pl-PL (pl_PL); UI-Language: pl-PL
Calc: CL

[Libreoffice-commits (libreoffice-commits)]

Armin Le Grand committed a patch related to this issue.
It has been pushed to "libreoffice-6-3":

https://git.libreoffice.org/core/commit/e8720057aa0f4e612000d68f6de682f3afb8a1ea

tdf#121963 apply GridOffset in isPrimitiveVisible

It will be available in 6.3.4.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

[Oliver-brinzing (oliver-brinzing)]

*** Bug 128685 has been marked as a duplicate of this bug. ***

[Broe375 (broe375)]

I have just installed LO 6.3.3 and the problem is NOT fixed.
I have two macro buttons and one of them "vibrates" as if being constantly pressed.

[Xiscofauli (xiscofauli)]

(In reply to Kino from comment #62)
> I have just installed LO 6.3.3 and the problem is NOT fixed.
> I have two macro buttons and one of them "vibrates" as if being constantly
> pressed.

it's fixed in LibreOffice 6.3.4 which is going to be released next week

[Oliver-brinzing (oliver-brinzing)]

*** Bug 129285 has been marked as a duplicate of this bug. ***

[Oliver-brinzing (oliver-brinzing)]

*** Bug 129718 has been marked as a duplicate of this bug. ***

[Libreoffice-commits (libreoffice-commits)]

Xisco Fauli committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/0d3d40b2668c879d8deb3b39f7c243e22b70bdcb

tdf#121963: Add unittest

It will be available in 7.0.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

[Tim Passingham (tim-8aw3u04umo)]

Until prompted by the status change (mentioning 6.3.4) on this I hadn't checked it, expecting to have to wait for 6.4 on ubuntu.

I can confirm it's fixed in Version: 6.3.5.1
Build ID: 1:6.3.5~rc1-0ubuntu0.19.10.1~lo1
CPU threads: 8; OS: Linux 5.3; UI render: default; VCL: x11;
Locale: en-GB (en_GB.UTF-8); UI-Language: en-GB
Calc: threaded

[Libreoffice-commits (libreoffice-commits)]

Xisco Fauli committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/2f9b7f4d7d35d0e2d85132792f8c74c54f05d6c1

tdf#121963: Add unittest (part 2)

It will be available in 7.0.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.