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
Created attachment 164862 [details] This file manifests the bug. See description.
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
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
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
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
(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.
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
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?
(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? Read comment 4
(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?
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.
[Automated Action] NeedInfo-To-Unconfirmed
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.
Nothing is shown in my case.
I tried it. Nothing was shown.
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 49e114d3803178f8720620834f97e2ab0962e826 source 49e114d3803178f8720620834f97e2ab0962e826 instdir/program/libslideshowlo.so | Bin 2557872 -> 2557872 bytes instdir/program/versionrc | 2 +- 2 files changed, 1 insertion(+), 1 deletion(-)
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.
Created attachment 165896 [details] simpler repro file
6.2.8.2 does not exhibit the bug, 6.3.6.2 does. This must have broken somewhere in-between.
(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
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
Is this bug (https://bugs.documentfoundation.org/show_bug.cgi?id=137212) a duplicate of this one?
*** Bug 137212 has been marked as a duplicate of this bug. ***
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)
At this point this bug has been multiply reproduced, and it has been bibisected. What more needs to be done before it is assigned?
(In reply to Mark from comment #25) > At this point this bug has been multiply reproduced, and it has been > bibisected. What more needs to be done before it is assigned? just a little patience
(In reply to BogdanB from comment #16) > Bibisected: ... > source 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.
It has been a month since Roman Kuznetsov told me to be patient. In that time I have been watching META- Bug 103610 hoping to see this bug climb to the top of the list to get assigned. There has been activity. Another bug was added to the list after this one, but the ninety ahead of this bug haven’t budged. Am I going to have to wait ninety months before this bug is looked at? The bug at the head of the list, 33154, is approaching its tenth anniversary. Am I going to have to wait ninety decades? Do you have so many high level bugs that medium level bugs never get looked at? That would be a red flag! How patient do I have to be?
I'll take it soon. Sorry for the regression.
(In reply to Mark from comment #28) > It has been a month since Roman Kuznetsov told me to be patient. In that > time I have been watching META- Bug 103610 hoping to see this bug climb to > the top of the list to get assigned. There has been activity. Another bug > was added to the list after this one, but the ninety ahead of this bug > haven’t budged. Am I going to have to wait ninety months before this bug is > looked at? The bug at the head of the list, 33154, is approaching its tenth > anniversary. Am I going to have to wait ninety decades? Do you have so > many high level bugs that medium level bugs never get looked at? That would > be a red flag! How patient do I have to be? Please do not put this sort of pressure on someone you didn't hire to work on a bug.
(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..
(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.
(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.
Let me say that I am fine with it taking over a month to assign this bug. The reason for my last comment was that I thought it had been put in a medium level bug graveyard. Gülşah Köse’s comment indicates that that is not the case. That has calmed me down quite a bit. 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? Perhaps I don’t know what I’m looking at. I was going to defend the commit from Telesto, but then he made his “Sorry, didn't intend to be disrespectful or rude.” comment. I feel you. Same here.
(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.
This report is too long and with off-topic so I didn't read. Could someone confirm that this is different from bug 134133? Or it's a duplicate with spending of volunteers on talk, bibisect.
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).
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 ***
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
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.
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
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.
(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.
@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.
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 :(
@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.
(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.
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?
(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!
@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?
It will be fixed with https://gerrit.libreoffice.org/c/core/+/108559 Thanks again
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.
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
@Pierre On the way
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.
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.
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?)
... indeed. LO 7.1.0.2 prerelease works way better (and also doesn't have the bug anymore).
(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.