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
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)
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
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
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
Build ID: 5b168b3fa568e48e795234dc5fa454bf24c9805e
CPU Threads: 4; OS Version: Linux 4.8; UI Render: default;
Locale: ca-ES (ca_ES.UTF-8)
Build ID: c15927f20d4727c3b8de68497b6949e72f9e6e9e
but not in
Version 22.214.171.124.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?
dadd589cd0633db4e126f0a6ab2907ffeef34563 is the first bad commit
Author: Matthew Francis <email@example.com>
Date: Fri Sep 18 10:13:10 2015 +0800
Bibisect: This commit covers the following source commit(s) which failed to build
Author: Michael Meeks <firstname.lastname@example.org>
AuthorDate: Mon Dec 17 19:55:32 2012 +0000
Commit: Michael Meeks <email@example.com>
CommitDate: Mon Dec 17 19:57:54 2012 +0000
fdo#58399 - revert attempts to untangle and accelerate this mess.
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 ? =)
(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.
3. After 67f899e1d2db0dccde4b9587a52b7157fe1fb0be, before 76350361f386b78e1bc9edb75af89e7ff3afe356.
4. After 76350361f386b78e1bc9edb75af89e7ff3afe356, before the reverting bb3f2900a867fdcb6df916fff58199b4ce94dd05.
5. After the reverting bb3f2900a867fdcb6df916fff58199b4ce94dd05.
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 126.96.36.199, 188.8.131.52, 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.