Created attachment 162980 [details] Sample PPTX slide How to repeat: 1. Open the attached presentation 2. Observe there are two text boxes and two lines shown. 3. Activate presentation mode 4. Observe there is only one text box and one lines shown Office 365 shows two text boxes and two lines, both in edit mode and in presentation mode.
Created attachment 162982 [details] How it looks in LibreOffice (presentation mode, step 4)
Created attachment 162983 [details] How it looks in Office 365 (presentation mode)
Reproduced with Version: 6.4.4.2 Build ID: 40(Build:2) CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3; Locale: en-US (en_US.UTF-8); UI-Language: en-US and Version: 7.0.0.1.0+ Build ID: a5f95804c1a730fb393c33b49e6fbe0f5a5e9eac CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:libreoffice-7-0, Time: 2020-07-05_20:25:33
Reproduced in Version: 7.1.0.0.alpha0+ Build ID: 00be56d9db396d284f66ab723d6fbb898b888dfb CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Version: 5.2.0.0.alpha1+ Build ID: 5b168b3fa568e48e795234dc5fa454bf24c9805e CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; Locale: ca-ES (ca_ES.UTF-8) Version: 4.3.0.0.alpha1+ Build ID: c15927f20d4727c3b8de68497b6949e72f9e6e9e but not in Version 4.1.0.0.alpha0+ (Build ID: efca6f15609322f62a35619619a6d5fe5c9bd5a)
This seems to have begun at the below commit. Adding Cc: to Michael Meeks ; Could you possibly take a look at this one? Thanks bibisect-41max: dadd589cd0633db4e126f0a6ab2907ffeef34563 is the first bad commit commit dadd589cd0633db4e126f0a6ab2907ffeef34563 Author: Matthew Francis <mjay.francis@gmail.com> Date: Fri Sep 18 10:13:10 2015 +0800 source-hash-bb3f2900a867fdcb6df916fff58199b4ce94dd05 Bibisect: This commit covers the following source commit(s) which failed to build 34e79c19babc0e6cc281025b40635b91dca444f3 542ad7f1c5ac7794c42248ac13e9b33f84888490 a108f4b14e119736c6a24f00cbfe87acb71e1e4a f828e91d1b2f0491e3d1c724ddd12f1b9177f466 97b583a7bfb5dc9000290c3bdc8df8751a97d65d 355c30789e311aa13d7421ce653dc80a9030c2e2 commit bb3f2900a867fdcb6df916fff58199b4ce94dd05 Author: Michael Meeks <michael.meeks@suse.com> AuthorDate: Mon Dec 17 19:55:32 2012 +0000 Commit: Michael Meeks <michael.meeks@suse.com> CommitDate: Mon Dec 17 19:57:54 2012 +0000 fdo#58399 - revert attempts to untangle and accelerate this mess. Reverts commits: 76350361f386b78e1bc9edb75af89e7ff3afe356 67f899e1d2db0dccde4b9587a52b7157fe1fb0be 1d77d4eada214e14938336070b248c18705939ff 1d16f59023b1b19d01ca69b8c9735be6d3baf5d9 The bug has a great series of linked bugs and stack-traces; the weakref / mixed tools & UNO lifecycle here is simply hideous.
I'd be surprised if this caused the issue - it is ultimately a revert of a problematic optimization so the state before 1d16f59023b1b19d01ca69b8c9735be6d3baf5d9 should be as before. Any chance you can try it before the oldest of those four mentioned reverted commits to see if we need to continue bisecting backwards ? =) Thanks !
(In reply to Michael Meeks from comment #6) > I'd be surprised if this caused the issue - it is ultimately a revert of a > problematic optimization so the state before > 1d16f59023b1b19d01ca69b8c9735be6d3baf5d9 should be as before. Any chance you > can try it before the oldest of those four mentioned reverted commits to see > if we need to continue bisecting backwards ? =) The situation is quite interesting, let's go in order of oldest to newest of the four reverted commits. The only bibisect repo covering those is bibisect-43all, which doesn't cover individual commits, but we can assume that in the result ranges (one commit in the bibisect repo) including one or more of the reverted commits, only those commits mattered. 1. Before 1d16f59023b1b19d01ca69b8c9735be6d3baf5d9 / 1d77d4eada214e14938336070b248c18705939ff. Bad. These two commits fall in a single commit in the bibisect repo. 2. After 1d16f59023b1b19d01ca69b8c9735be6d3baf5d9 / 1d77d4eada214e14938336070b248c18705939ff, before 67f899e1d2db0dccde4b9587a52b7157fe1fb0be. Good. 3. After 67f899e1d2db0dccde4b9587a52b7157fe1fb0be, before 76350361f386b78e1bc9edb75af89e7ff3afe356. Bad. 4. After 76350361f386b78e1bc9edb75af89e7ff3afe356, before the reverting bb3f2900a867fdcb6df916fff58199b4ce94dd05. Good. 5. After the reverting bb3f2900a867fdcb6df916fff58199b4ce94dd05. Bad. The ranges belonging to the bibisect-43all repo including the later reverted commits: - First two: https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=bec62421a45da89d2812bdff30fbbab73291cf91..f260c656da4457c5d87c161bdd43ad3023d07472 - Third: https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=683758efb22d08a4cf211a6d985148f513da2a90..a599f5b4b51848e3b397d471c9d12b373caadcef - Fourth: https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=4026e1824de8ff9b5d006ae6eba491f91bc4e599..ce90f99a2d66c2b998ad3f9f028e2ea623a757f5 Since it was also bad in 4.0.0.3, 3.6.0.4, ie. no release version included the above commits, let's remove the keyword regression.
Ah - a wonderful example of a commit accidentally fixing one bug, but creating a slew of other regressions. From what I recall of the subtle side-effects of this one item cache: + // We get dozens of back-to-back calls for the same shape + if( pCustomShape == g_pLastCacheShape ) + return xCustomShapeEngine; That the previous author wrote: - Reference< XCustomShapeEngine > xCustomShapeEngine( GetCustomShapeEngine( this ) ); // a candidate for being cached ;-) gave a really nice performance win for a while, and seemed clean - but ... I guess something there is biting us in the coupling.
In addition to the findings in the original bug description, if I change all four animation elements to "on click" and then start the presentation - nothing *ever* shows, just a white screen, and the presentation ends after four clicks.
Dear Gerald Pfeifer, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
This still reproduces with today's nightly build: Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 125fc2ce861c82592b261f2992c893b414396e56 CPU threads: 12; OS: Linux 6.6; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US