Download it now!
Bug 134785 - FILEOPEN PPTX: text box and line not shown in presentation mode
Summary: FILEOPEN PPTX: text box and line not shown in presentation mode
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
4.1.0.4 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected
Depends on:
Blocks: Slide-Show
  Show dependency treegraph
 
Reported: 2020-07-13 14:21 UTC by Gerald Pfeifer
Modified: 2020-09-12 14:39 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Sample PPTX slide (38.09 KB, application/vnd.openxmlformats-officedocument.presentationml.presentation)
2020-07-13 14:21 UTC, Gerald Pfeifer
Details
How it looks in LibreOffice (presentation mode, step 4) (7.20 KB, image/png)
2020-07-13 14:21 UTC, Gerald Pfeifer
Details
How it looks in Office 365 (presentation mode) (9.98 KB, image/png)
2020-07-13 14:22 UTC, Gerald Pfeifer
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Gerald Pfeifer 2020-07-13 14:21:10 UTC
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.
Comment 1 Gerald Pfeifer 2020-07-13 14:21:51 UTC
Created attachment 162982 [details]
How it looks in LibreOffice (presentation mode, step 4)
Comment 2 Gerald Pfeifer 2020-07-13 14:22:24 UTC
Created attachment 162983 [details]
How it looks in Office 365 (presentation mode)
Comment 3 Gerald Pfeifer 2020-07-13 14:23:57 UTC
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
Comment 4 Xisco Faulí 2020-07-13 15:32:16 UTC
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)
Comment 5 raal 2020-09-09 20:10:31 UTC
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.
Comment 6 Michael Meeks 2020-09-10 14:17:43 UTC
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 !
Comment 7 Aron Budea 2020-09-11 22:55:08 UTC
(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.
Comment 8 Michael Meeks 2020-09-12 14:39:13 UTC
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.