Bug 136278 - The left arrow key causes objects to disappear.
Summary: The left arrow key causes objects to disappear.
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
6.4.0.0.beta1+
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:7.2.0 target:7.1.0.2 target:7.0.5
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Slide-Show
  Show dependency treegraph
 
Reported: 2020-08-30 03:19 UTC by Mark
Modified: 2021-01-25 07:57 UTC (History)
11 users (show)

See Also:
Crash report or crash signature:


Attachments
This file manifests the bug. See description. (114.12 KB, application/vnd.oasis.opendocument.presentation)
2020-08-30 03:25 UTC, Mark
Details
simpler repro file (14.07 KB, application/vnd.oasis.opendocument.presentation)
2020-09-27 20:39 UTC, Horst Schirmeier
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mark 2020-08-30 03:19:56 UTC
Description:
I am running the attached file – Impress_Issue.odp - on a system76 Gazelle laptop using LibreOffice V.6.4.5.2.  Here’s the specs: 

NAME="Pop!_OS"
VERSION="20.04 LTS"
ID=pop
ID_LIKE="ubuntu debian"
PRETTY_NAME="Pop!_OS 20.04 LTS"
VERSION_ID="20.04"
HOME_URL="https://pop.system76.com"
SUPPORT_URL="https://support.system76.com"
BUG_REPORT_URL="https://github.com/pop-os/pop/issues"
PRIVACY_POLICY_URL="https://system76.com/privacy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal
LOGO=distributor-logo-pop-os
Linux pop-os 5.4.0-7642-generic #46~1597422484~20.04~e78f762-Ubuntu SMP Wed Aug 19 14:35:06 UTC  x86_64 x86_64 x86_64 GNU/Linux



To see how the slide is supposed to work:
 	Open Impress_Issue.odp in LibreOffice Impress.
	Hit F5 to start.
	Hit Enter until the slide is finished.

To see how the slide is not supposed to work:
 	Open Impress_Issue.odp in LibreOffice Impress.
	Hit F5 to start.
	Hit Enter sixteen times.  You should be at the point where 2.5m in the variable legend has just changed to +2.5m.
	Hit the left key.  The +2.5m will change back to 2.5m as it should, but the variable legend label disappears. - BUG.
	Hit Enter twice.  The 2.5m changes back to +2.5m on the first hit as it should.  It does not change to -2.5m on the second hit – BUG. 
	I put a video demo of the bug on YouTube.  I didn’t give it any search parameters.
  https://youtu.be/c0NxOQ7UZcc 


Steps to Reproduce:
1.Open file Impress_Issue.odp
2.Hit F5
3.Hit Enter 16 times
4.Hit Left arrow.  'Variable Legend' disappears.

Actual Results:
1.Open file Impress_Issue.odp
2.Hit F5
3.Hit Enter 16 times
4.Hit Left arrow.  'Variable Legend' disappears.

Expected Results:
1. +2.5m would revert to 2.5m.  This did happened.
2. 'Variable Legend' would stay in place. This didn't happen.


Reproducible: Always


User Profile Reset: Yes


OpenGL enabled: Yes

Additional Info:
Version: 6.4.5.2
Build ID: 1:6.4.5-0ubuntu0.20.04.1
CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3; 
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: threaded
Comment 1 Mark 2020-08-30 03:25:11 UTC
Created attachment 164862 [details]
This file manifests the bug.  See description.
Comment 2 BogdanB 2020-08-30 05:36:36 UTC
I confirm this bug in my version. But I will let developers to investigate further.

Version: 6.4.5.2
Build ID: a726b36747cf2001e06b58ad5db1aa3a9a1872d6
CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3; 
Locale: ro-RO (ro_RO.UTF-8); UI-Language: en-US
Calc: threaded
Comment 3 BogdanB 2020-08-30 05:43:00 UTC
Repro in
Version: 6.4.4.1
Build ID: b50bc319eca5cd5b66fbfe2ebd0d3bd1eed099b5
CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3; 
Locale: ro-RO (ro_RO.UTF-8); UI-Language: en-US
Calc: threaded

---- here began the problem ----

Don't repro in
Version: 6.4.3.2
Build ID: 747b5d0ebf89f41c860ec2a39efd7cb15b54f2d8
CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3; 
Locale: ro-RO (ro_RO.UTF-8); UI-Language: en-US
Calc: threaded

Don't repro in
Version: 6.4.2.2
Build ID: 4e471d8c02c9c90f512f7f9ead8875b57fcb1ec3
CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3; 
Locale: ro-RO (ro_RO.UTF-8); UI-Language: en-US
Calc: threaded

Don't repro in
Version: 6.3.5.2
Build ID: dd0751754f11728f69b42ee2af66670068624673
CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3; 
Locale: ro-RO (ro_RO.UTF-8); UI-Language: en-US
Calc: threaded
Comment 4 Buovjaga 2020-08-30 12:42:57 UTC
Not reproduced.

Arch Linux 64-bit
Version: 7.1.0.0.alpha0+
Build ID: d784e711c102f204552c3c816636da01b1085f61
CPU threads: 8; OS: Linux 5.8; UI render: default; VCL: gtk3
Locale: fi-FI (fi_FI.UTF-8); UI: en-US
Calc: threaded
Built on 29 August 2020

Arch Linux 64-bit
Version: 7.0.0.3
Build ID: 7.0.0-2
CPU threads: 8; OS: Linux 5.8; UI render: default; VCL: gtk3
Locale: fi-FI (fi_FI.UTF-8); UI: en-US
Calc: threaded
Comment 5 BogdanB 2020-08-30 13:01:41 UTC
Buovjaga, please see the video from youtube from description from minute 3:00 since 4:10. The legend is disapearing.

Repro in
Version: 7.1.0.0.alpha0+
Build ID: 217122387f6e0ef657b8ba85eae082b448901cec
CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3
Locale: ro-RO (ro_RO.UTF-8); UI: en-US
Calc: threaded

Repro in
Version: 7.0.0.0.beta2+
Build ID: 2bb5d9624911eb78ce5a3cd0aa122f9307c50a5c
CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3
Locale: ro-RO (ro_RO.UTF-8); UI: en-US
Calc: threaded
Comment 6 Buovjaga 2020-08-30 14:59:35 UTC
(In reply to BogdanB from comment #5)
> Buovjaga, please see the video from youtube from description from minute
> 3:00 since 4:10. The legend is disapearing.

Yes, I saw it disappears at 3:49. Not for me, though.
Comment 7 raal 2020-08-30 17:10:32 UTC
No repro Version: 7.1.0.0.alpha0+
Build ID: 217122387f6e0ef657b8ba85eae082b448901cec
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3
Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US
Calc: threaded
Ubuntu 18.04
Comment 8 BogdanB 2020-08-30 18:13:02 UTC Comment hidden (obsolete)
Comment 9 Buovjaga 2020-08-30 18:23:54 UTC Comment hidden (obsolete)
Comment 10 Roman Kuznetsov 2020-09-24 19:07:30 UTC
(In reply to BogdanB from comment #8)
> I have Ubuntu 20.04 and the bug.
> Mark has Ubuntu 20.04 and the bug.
> Raal has 18.04 and NO bug.
> Buovjaga, you?

It's just an Ubuntu build problem and I would close it as notourbug

Mark, can you test your file in LibreOffice from snap or appimage or flatpack packages?
Comment 11 Mark 2020-09-26 01:30:00 UTC
	I ran it in flatpak, but the bug was still there.  Does that tell us anything interesting?
	Does that mean I should go bother Canonical?  System76? The Debian Project?  Does this mean The Document Foundation doesn’t consider this their problem?  Ubuntu and its forks are very popular.  I would think that if LibreOffice doesn’t run reliably on them, The Document Foundation would consider that a problem.  This is a big bug.  I’ve only shown you a manifestation that is easily reproduced in a small file.  I’ve seen others.
	What’s the next move?  Is it yours or mine?  
	It occurs to me that notourbug might be premature.  There might be a bug after a line that looked something like this:
#ifdef 		DEBIAN
That would be a LibreOffice bug that was restricted to the Debian family of distributions, which is consistent with what we see. 
	If the problem was in Ubuntu, and if the Document Foundation took it on, you could do the following:
Step 1: Identify the call within Impress that Ubuntu was responding to inappropriately.
Step 2: Report the bug to Canonical.
I can only do step 2.  In that case it would be entirely reasonable for Canonical to say, “This is a bug within LibreOffice.”  Without step 1 I could end up with The Document Project and Canonical pointing fingers at each other, and the bug going unresolved.
	Yet another thing occurs to me.  Note that BogdanB could not reproduce the bug in anything prior to 6.4.4.1.  This suggests that something happened between 6.4.3.2 and 6.4.4.1 that made it incompatible with Ubuntu.  That would make it your bug.
Comment 12 QA Administrators 2020-09-26 03:54:50 UTC Comment hidden (obsolete)
Comment 13 Buovjaga 2020-09-26 06:52:10 UTC
If you repro with Flatpak, it is not an Ubuntu packaging issue.

Give this command in the terminal:

env|grep WAYLAND

If nothing is shown, you are running under X11. If you see WAYLAND_DISPLAY=... you are running a Wayland session. Would be interesting to know. Same for Bogdan btw.
Comment 14 BogdanB 2020-09-26 07:18:21 UTC
Nothing is shown in my case.
Comment 15 Mark 2020-09-27 01:44:38 UTC
I tried it. Nothing was shown.
Comment 16 BogdanB 2020-09-27 20:18:13 UTC
Bibisected:

019dc7f2985afffc4a18f8e126b674c373a4c6fe is the first bad commit
commit 019dc7f2985afffc4a18f8e126b674c373a4c6fe
Author: Jenkins Build User <tdf@pollux.tdf>
Date:   Sun Mar 29 18:12:12 2020 +0200

    source sha:49e114d3803178f8720620834f97e2ab0962e826
    
    source sha:49e114d3803178f8720620834f97e2ab0962e826

 instdir/program/libslideshowlo.so | Bin 2557872 -> 2557872 bytes
 instdir/program/versionrc         |   2 +-
 2 files changed, 1 insertion(+), 1 deletion(-)
Comment 17 Horst Schirmeier 2020-09-27 20:38:44 UTC
I can reproduce the issue with the latest LibreOffice 7.0.1.2 (DEB) from libreoffice.org, and with Ubuntu 20.04's LibreOffice 6.4.6-0ubuntu0.20.04.1 (with KDE on Xorg).  I see this all over the place in my own presentations.  I'll attach a much simpler file that reproduces the issue.
Comment 18 Horst Schirmeier 2020-09-27 20:39:43 UTC
Created attachment 165896 [details]
simpler repro file
Comment 19 Horst Schirmeier 2020-09-27 20:51:53 UTC Comment hidden (obsolete)
Comment 20 Buovjaga 2020-09-28 05:07:24 UTC
(In reply to Horst Schirmeier from comment #19)
> 6.2.8.2 does not exhibit the bug, 6.3.6.2 does.  This must have broken
> somewhere in-between.

Well, Bogdan bisected it to the exact cause before your comment already.

It was cherry-picked to 6.3, but was originally done for 6.4: https://gerrit.libreoffice.org/c/core/+/91118
Comment 21 BogdanB 2020-09-28 05:34:35 UTC
Gulsah Kose, please if you can take a look on this bug. I add you to CC on this bug.

Bibisected:
https://git.libreoffice.org/core/commit/49e114d3803178f8720620834f97e2ab0962e826
Comment 22 BogdanB 2020-10-02 19:46:55 UTC
Is this bug (https://bugs.documentfoundation.org/show_bug.cgi?id=137212) a duplicate of this one?
Comment 23 BogdanB 2020-10-02 19:47:57 UTC
*** Bug 137212 has been marked as a duplicate of this bug. ***
Comment 24 Pierre C 2020-10-02 20:12:42 UTC
Confirming a bug with LO 7.0.2.1. W10

Using left arrow key should animate back (The last object that has appeared should be the first to disappear)
Comment 25 Mark 2020-10-05 21:38:32 UTC Comment hidden (no-value)
Comment 26 Roman Kuznetsov 2020-10-06 08:30:50 UTC Comment hidden (obsolete)
Comment 27 Aron Budea 2020-10-18 15:09:43 UTC
(In reply to BogdanB from comment #16)
> Bibisected:
...
>     source sha:49e114d3803178f8720620834f97e2ab0962e826
Let's list the master commit here, too:

https://cgit.freedesktop.org/libreoffice/core/commit/?id=80f386f787ad59936ead2022e6d932a6d441c6e9
author		Gülşah Köse <gulsah.kose@collabora.com>	2020-03-23 15:33:40 +0300
committer	Gülşah Köse <gulsah.kose@collabora.com>	2020-03-26 19:36:07 +0100

tdf#131254 Prevent extra eventqueue empty call.
Comment 28 Mark 2020-11-06 21:13:46 UTC Comment hidden (no-value)
Comment 29 Gülşah Köse 2020-11-06 22:06:06 UTC
I'll take it soon. Sorry for the regression.
Comment 30 Buovjaga 2020-11-07 05:25:16 UTC Comment hidden (obsolete)
Comment 31 Telesto 2020-11-07 19:37:11 UTC
(In reply to Buovjaga from comment #30)
> Please do not put this sort of pressure on someone you didn't hire to work
> on a bug.

Pressure can be relieved by temporally reverting they commit in question. I (personally) don't call the issue solved major. However no clue about the origin of they issue. They developer himself running into it or say - for example - a paying customer..
Comment 32 Buovjaga 2020-11-08 07:53:48 UTC
(In reply to Telesto from comment #31)
> (In reply to Buovjaga from comment #30)
> > Please do not put this sort of pressure on someone you didn't hire to work
> > on a bug.
> 
> Pressure can be relieved by temporally reverting they commit in question. I
> (personally) don't call the issue solved major. However no clue about the
> origin of they issue. They developer himself running into it or say - for
> example - a paying customer..

This is not OK either. You add Xisco to the report while implying the commit should be reverted even though Gülşah just said she will look into it. Have some respect, please.
Comment 33 Telesto 2020-11-08 08:47:36 UTC
(In reply to Buovjaga from comment #32)
> This is not OK either. You add Xisco to the report while implying the commit
> should be reverted even though Gülşah just said she will look into it. Have
> some respect, please.

Sorry, didn't intend to be disrespectful or rude. Was more intended to 'help out'. Even though not properly communicated and open for (mis)interpretation.
 They idea was indeed to temporally revert the commit, so Gülşah having time to look into it without outside pressure or feeling a need to looking into it out of politeness (while say been really busy; and actually not having much time available; say even for a revert). They latter of course me speculating without knowing.
Comment 34 Mark 2020-11-10 01:22:52 UTC Comment hidden (no-value)
Comment 35 Buovjaga 2020-11-10 09:00:34 UTC
(In reply to Mark from comment #34)
> 	As to the fact that I am not paying for the fix: I thought that that meant
> I wasn’t in a position to put pressure on anyone. I was surprised that it
> was taken that way.  I was expressing a concern and the basis for that
> concern.  I’m still concerned, not about this bug, but about what looks to
> me like an out of control bug list.  Am I wrong?

You are completely right about the bug list being out of control. You are very welcome to help in this way which does not require programming skills: https://wiki.documentfoundation.org/QA/GetInvolved#Quick_start_guide_for_beginners

If you are interested in helping, please email me and we will schedule an orienting interview.
Comment 36 Timur 2020-11-14 10:32:11 UTC Comment hidden (obsolete)
Comment 37 Horst Schirmeier 2020-11-14 18:06:04 UTC
It's been bibisected to the same commit, so I'd guess it's the same bug.

However, the description in bug #134133 seems to only partially describe the problem; using the left arrow can lead to visual states that cannot be reached going only forward (e.g. additional missing objects).
Comment 38 Telesto 2020-11-15 18:48:50 UTC
Marking this a duplicate of bug 134133 for the time being.. can be rechecked again if resolved.

*** This bug has been marked as a duplicate of bug 134133 ***
Comment 39 Gülşah Köse 2020-12-30 10:41:36 UTC
Hi Aron and Bogdan,

I think there is a bug here before, my commit made the situation worse but it is reverted again to first state with my second patch.


Any chance to check my comment about the bug. 
https://bugs.documentfoundation.org/show_bug.cgi?id=134133#c15
Comment 40 Horst Schirmeier 2020-12-30 12:33:03 UTC
Bug #134133 is now marked as "fixed", but this bug still persists -- with slightly different behavior (tested with master~2020-12-28_21.50.05_LibreOfficeDev_7.2.0.0.alpha0_Linux_x86-64_deb.tar.gz); also see Gülşah's comment.

Still reproducible with my attachment "simpler repro file", but now with different behavior:
- Start presentation with F5, 5x right arrow, 5x left arrow, 5x right arrow.
- Expected: Presentation should be in final state (five visible blue boxes).
- Instead: After 4x right arrow I see 3(!) blue boxes (#1, #2, and #4; #3 is missing), and after one additional right-arrow keypress (5 in total) the presentation surprisingly is in the white-on-black "Click to exit presentation..." end state.
Comment 41 Pierre C 2020-12-30 16:06:23 UTC
Reproducible with "simpler repro file" as described by Horst Schirmeier
with latest LO 7.2 dev windows 10
Version: 7.2.0.0.alpha0+ (x64)
Build ID: f72a5fd03ddfa94b074b28cf1259284f727139f0
CPU threads: 8; OS: Windows 10.0 Build 19042; UI render: Skia/Vulkan; VCL: win
Locale: fr-FR (fr_FR); UI: fr-FR
Calc: threaded
But works fine with LO 6.4.3.2 & W10
Comment 42 Gülşah Köse 2020-12-30 17:00:51 UTC
I can confirm the bug as described below. This is not a regression caused by me. It should be another regression. While bisecting please make sure that the bad situation is like as below.

> 
> Still reproducible with my attachment "simpler repro file", but now with
> different behavior:
> - Start presentation with F5, 5x right arrow, 5x left arrow, 5x right arrow.
> - Expected: Presentation should be in final state (five visible blue boxes).
> - Instead: After 4x right arrow I see 3(!) blue boxes (#1, #2, and #4; #3 is
> missing), and after one additional right-arrow keypress (5 in total) the
> presentation surprisingly is in the white-on-black "Click to exit
> presentation..." end state.
Comment 43 Buovjaga 2020-12-30 19:07:34 UTC
(In reply to Gülşah Köse from comment #42)
> I can confirm the bug as described below. This is not a regression caused by
> me. It should be another regression. While bisecting please make sure that
> the bad situation is like as below.
> 
> > 
> > Still reproducible with my attachment "simpler repro file", but now with
> > different behavior:
> > - Start presentation with F5, 5x right arrow, 5x left arrow, 5x right arrow.
> > - Expected: Presentation should be in final state (five visible blue boxes).
> > - Instead: After 4x right arrow I see 3(!) blue boxes (#1, #2, and #4; #3 is
> > missing), and after one additional right-arrow keypress (5 in total) the
> > presentation surprisingly is in the white-on-black "Click to exit
> > presentation..." end state.

Contrary to comment 39, there was no bug before. I double-checked it with linux-64-7.0 repo.

Now the regression has changed with https://git.libreoffice.org/core/commit/a63caf49958b40e33e0d7aaedbe6424f78ecdc46 to the one described by Horst in comment 40. I bibisected it with linux-64-7.2.
Comment 44 Gülşah Köse 2021-01-01 13:36:10 UTC
@Buovjaga I reverted my two commits on current master.

commit 5cc188f711a3f2afa13bd69a92240f3a69213c1a (HEAD -> master)
Author: Gülşah Köse <gulsah.kose@collabora.com>
Date:   Fri Jan 1 16:29:12 2021 +0300

    Revert "tdf#131254 Prevent extra eventqueue empty call."
    
    This reverts commit 80f386f787ad59936ead2022e6d932a6d441c6e9.

commit 9f47b9065d2319de6a4070b7aa09b386fbeb11c3
Author: Gülşah Köse <gulsah.kose@collabora.com>
Date:   Fri Jan 1 16:28:39 2021 +0300

    Revert "tdf#134133 Check when the eventqueue needs to be emptied."
    
    This reverts commit a63caf49958b40e33e0d7aaedbe6424f78ecdc46.

And problem still exists. How do you explain this? Most probably bibisect linux-64-7.0 repo doesn't contain the problematic commit.

 
> Contrary to comment 39, there was no bug before. I double-checked it with
> linux-64-7.0 repo.
> 
> Now the regression has changed with
> https://git.libreoffice.org/core/commit/
> a63caf49958b40e33e0d7aaedbe6424f78ecdc46 to the one described by Horst in
> comment 40. I bibisected it with linux-64-7.2.
Comment 45 Buovjaga 2021-01-01 14:04:45 UTC
You are right that reverting both of the commits in current master does not make the newest badness go away (I tested it).

Now I bibisected again more carefully with 7.2 repo, making the full three rounds of five arrow key presses every time. I still get a63caf49958b40e33e0d7aaedbe6424f78ecdc46 as the commit when it appeared. So like you say, there is some other underlying code change causing this, but it can not be found out by using the binary bisect repos :(
Comment 46 Gülşah Köse 2021-01-01 14:15:47 UTC
@Buovjaga thanks for the confirmation. I've added notBibisectable keyword to explain this situation. There shouldn't be magic here. I think bibisect repo has missing commit. Do you know how can we check this? I saw the @Xisco were maintaining that repo. Maybe he can help.
Comment 47 Buovjaga 2021-01-01 14:28:58 UTC
(In reply to Gülşah Köse from comment #46)
> @Buovjaga thanks for the confirmation. I've added notBibisectable keyword to
> explain this situation. There shouldn't be magic here. I think bibisect repo
> has missing commit. Do you know how can we check this? I saw the @Xisco were
> maintaining that repo. Maybe he can help.

There is no commit missing between bad/good in the 7.2 bibisect repo. It seems there was some change between 7.0 and 7.2, which modified behaviour in some non-manifesting way, which your a63caf49958b40e33e0d7aaedbe6424f78ecdc46 then triggered into the newest badness.
Comment 48 Aron Budea 2021-01-01 14:35:57 UTC
Gülşah, Buovjaga, please note that there's another related commit in bug 131254:
https://cgit.freedesktop.org/libreoffice/core/commit/?id=14a0727889699128f02ac0a79bdce0103c89bc01

I don't have a fresh master build that includes the most recent fix, can you give reverting the above commit in addition to the previously mentioned two a try?
Comment 49 Buovjaga 2021-01-01 14:40:03 UTC
(In reply to Aron Budea from comment #48)
> Gülşah, Buovjaga, please note that there's another related commit in bug
> 131254:
> https://cgit.freedesktop.org/libreoffice/core/commit/
> ?id=14a0727889699128f02ac0a79bdce0103c89bc01
> 
> I don't have a fresh master build that includes the most recent fix, can you
> give reverting the above commit in addition to the previously mentioned two
> a try?

Ooh, you hit gold! Indeed, including the follow-up commit in the reverted ones makes the badness go away!
Comment 50 Gülşah Köse 2021-01-01 14:50:12 UTC
@Aron a gold medal comes to you from me. I'll fix it in 10 minutes now. Thank you so much.

(In reply to Aron Budea from comment #48)
> Gülşah, Buovjaga, please note that there's another related commit in bug
> 131254:
> https://cgit.freedesktop.org/libreoffice/core/commit/
> ?id=14a0727889699128f02ac0a79bdce0103c89bc01
> 
> I don't have a fresh master build that includes the most recent fix, can you
> give reverting the above commit in addition to the previously mentioned two
> a try?
Comment 51 Gülşah Köse 2021-01-01 15:14:11 UTC
It will be fixed with https://gerrit.libreoffice.org/c/core/+/108559 Thanks again
Comment 52 Commit Notification 2021-01-03 19:18:22 UTC
Gülşah Köse committed a patch related to this issue.
It has been pushed to "master":

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

tdf#136278 Follow-up Check when the eventqueue needs to be emptied.

It will be available in 7.2.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.
Comment 53 Pierre C 2021-01-04 05:57:58 UTC
tested this morning with LO 7.2 dev
Version: 7.2.0.0.alpha0+ (x64)
Build ID: 96bafa464ebdbce3ef04bec9beae5e745bb37794
CPU threads: 8; OS: Windows 10.0 Build 19042; UI render: Skia/Vulkan; VCL: win
Locale: fr-FR (fr_FR); UI: fr-FR
Calc: threaded

All seems fine
Good job

Shouldn't this patch be backported to LO 7.1 and 7.0 branch ?
Pierre
Comment 54 Gülşah Köse 2021-01-04 06:01:48 UTC
@Pierre On the way
Comment 55 Commit Notification 2021-01-05 08:32:11 UTC
Gülşah Köse committed a patch related to this issue.
It has been pushed to "libreoffice-7-1":

https://git.libreoffice.org/core/commit/09c4b4dbf7bb1dc4821455b0e0f549954f1c4002

tdf#136278 Follow-up Check when the eventqueue needs to be emptied.

It will be available in 7.1.0.2.

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.
Comment 56 Commit Notification 2021-01-05 15:38:53 UTC
Gülşah Köse committed a patch related to this issue.
It has been pushed to "libreoffice-7-0":

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

tdf#136278 Follow-up Check when the eventqueue needs to be emptied.

It will be available in 7.0.5.

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.
Comment 57 Horst Schirmeier 2021-01-24 20:29:00 UTC
Tested with libreoffice-7-1~2021-01-21_04.37.55_LibreOfficeDev_7.1.1.0.0_Linux_x86-64_deb.tar.gz , I don't observe the issue anymore.  Thank you!

(But LO Impress feels slower than ever.  Is this a non-optimized debug build?)
Comment 58 Horst Schirmeier 2021-01-24 20:50:21 UTC
... indeed.  LO 7.1.0.2 prerelease works way better (and also doesn't have the bug anymore).
Comment 59 Buovjaga 2021-01-25 07:55:28 UTC
(In reply to Horst Schirmeier from comment #57)
> Tested with
> libreoffice-7-1~2021-01-21_04.37.55_LibreOfficeDev_7.1.1.0.0_Linux_x86-
> 64_deb.tar.gz , I don't observe the issue anymore.  Thank you!
> 
> (But LO Impress feels slower than ever.  Is this a non-optimized debug
> build?)

The debug builds have "dbg" in the archive name, so your build sounds normal. Debug builds indeed have a performance hit.