Bug 84643 - Upon copying a slide, the new slide is assigned the wrong template
Summary: Upon copying a slide, the new slide is assigned the wrong template
Status: RESOLVED DUPLICATE of bug 85247
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
4.3.1.2 release
Hardware: x86 (IA32) All
: medium normal
Assignee: Muthu
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks:
 
Reported: 2014-10-04 00:25 UTC by madmaze
Modified: 2020-07-11 19:03 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Demo slideshow showing the issue with the template (12.16 KB, application/vnd.oasis.opendocument.presentation)
2014-10-04 05:01 UTC, Joey Reid
Details

Note You need to log in before you can comment on or make changes to this bug.
Description madmaze 2014-10-04 00:25:46 UTC
Problem description: 
If a slide is copied and pasted, a new template is created that is not identical to the slide that was originally copied.

Steps to reproduce:
1. Create new slideshow (One slide)
2. Add new slide (Two slides)
3. Copy and paste 2nd slide (Three slides)
4. Edit third slide(the copied one)

Current behavior:
It creates a second "Master" template called "Default_" which does not contain the footer sections (this is how I found the bug)

Expected behavior:
I would expect the copied slide to keep the same template as the slide I copied, which is this case would be the "Default" template not "Default_"

If necessary I can put together screenshots on this bug, once I get this presentation done.
Comment 1 madmaze 2014-10-04 00:27:13 UTC
I have found this bug on two independent systems (Debian and Ubuntu)
Comment 2 Joey Reid 2014-10-04 05:01:31 UTC
Created attachment 107300 [details]
Demo slideshow showing the issue with the template

Confirmed on Windows Version: 4.4.0.0.alpha0+
TinderBox: Win-x86@39, Branch:master, Time: 2014-10-03_00:31:27

I can confirm that after following the steps in the Description and then enabling page numbers, the 3rd, copied slide does not show the page number from the master slide. When I start a slideshow it is also BLUE instead of white.

When I follow the same steps in Apache OpenOffice, the 3rd, copied slide uses the master slide settings. It is both white and includes the page number.
Comment 3 madmaze 2014-10-04 12:46:35 UTC
Thanks for confirming my observations. 
One thing I wanted to point out is that enabling the page numbers is not necessary for the bug to happen, just for you to visually see it.

If, after every step, go to View->Master->Slide Master, you will see as soon as the copy is made a new template appears ("Default_") which does not match the original template of the slide copied. Interestingly a new template is only created upon the first copy and is then applied to every copied slide.
Comment 4 Terrence Enger 2014-10-05 17:45:29 UTC
From `git bisect skip`:

    There are only 'skip'ped commits left to test.
    The first bad commit could be any of:
    bb138a397a1f29902ce6c69bb161254832081623
    c2e967de61ee4b1291703af64dac729a8ada79fb
    7d9e0cb59cf7fe20b31a5c291238b5391834c278
    We cannot bisect more!

and from `git bisect log`:

    # bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e
    # good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932
    git bisect start 'latest' 'oldest'
    # good: [e02439a3d6297a1f5334fa558ddec5ef4212c574] source-hash-6b8393474974d2af7a2cb3c47b3d5c081b550bdb
    git bisect good e02439a3d6297a1f5334fa558ddec5ef4212c574
    # bad: [4850941efe43ae800be5c76e1102ab80ac2c085d] source-hash-980a6e552502f02f12c15bfb1c9f8e6269499f4b
    git bisect bad 4850941efe43ae800be5c76e1102ab80ac2c085d
    # skip: [a043626b542eb8314218d7439534dce2fc325304] source-hash-9379a922c07df3cdb7d567cc88dfaaa39ead3681
    git bisect skip a043626b542eb8314218d7439534dce2fc325304
    # skip: [aba65c3e4c0df07e4909aeefb758cdb688242bf6] source-hash-827524abfb4b577d08276fde40929a9adfb7ff1a
    git bisect skip aba65c3e4c0df07e4909aeefb758cdb688242bf6
    # skip: [aba65c3e4c0df07e4909aeefb758cdb688242bf6] source-hash-827524abfb4b577d08276fde40929a9adfb7ff1a
    git bisect skip aba65c3e4c0df07e4909aeefb758cdb688242bf6
    # good: [c81a8a0dcfc1ed095a80e4485c89dd0fcaf73f31] source-hash-c69ed33628ec0b7abf6296539cf280d6c4265930
    git bisect good c81a8a0dcfc1ed095a80e4485c89dd0fcaf73f31
    # good: [c81a8a0dcfc1ed095a80e4485c89dd0fcaf73f31] source-hash-c69ed33628ec0b7abf6296539cf280d6c4265930
    git bisect good c81a8a0dcfc1ed095a80e4485c89dd0fcaf73f31
    # good: [30cde618212ecaf5725321372bd1b8339f8e2b9f] source-hash-137f872aa8e6e598e7c7ed1ffa4d21e580e22bdb
    git bisect good 30cde618212ecaf5725321372bd1b8339f8e2b9f
    # good: [30cde618212ecaf5725321372bd1b8339f8e2b9f] source-hash-137f872aa8e6e598e7c7ed1ffa4d21e580e22bdb
    git bisect good 30cde618212ecaf5725321372bd1b8339f8e2b9f
    # bad: [306d62ec4b911895f08f2bb8efefebed7ac795f0] source-hash-735bd120c9ee2d9bb3514907936c27efb75d7282
    git bisect bad 306d62ec4b911895f08f2bb8efefebed7ac795f0
    # bad: [306d62ec4b911895f08f2bb8efefebed7ac795f0] source-hash-735bd120c9ee2d9bb3514907936c27efb75d7282
    git bisect bad 306d62ec4b911895f08f2bb8efefebed7ac795f0
    # good: [835ce851abe657bb5a8238693ea924287e6890c0] source-hash-1e53784811458563b36fd4cbaa15c2f526a7161b
    git bisect good 835ce851abe657bb5a8238693ea924287e6890c0
    # bad: [7d9e0cb59cf7fe20b31a5c291238b5391834c278] source-hash-c828319753558e25a48ce7808604bcc648f2483d
    git bisect bad 7d9e0cb59cf7fe20b31a5c291238b5391834c278
    # skip: [c2e967de61ee4b1291703af64dac729a8ada79fb] source-hash-17dab5bf8efb3fd676e6854474b199b681d0dc28
    git bisect skip c2e967de61ee4b1291703af64dac729a8ada79fb
    # good: [98483e4e4f5256c92649d861f8deaf380e234906] source-hash-fa7c24e0e7b300fb7ac6ff7202a57eb1c60eb0b6
    git bisect good 98483e4e4f5256c92649d861f8deaf380e234906
    # skip: [bb138a397a1f29902ce6c69bb161254832081623] source-hash-acf233e2bb259759c9167a32e17fcf13e1f54f6c
    git bisect skip bb138a397a1f29902ce6c69bb161254832081623
    # only skipped commits left to test
    # possible first bad commit: [7d9e0cb59cf7fe20b31a5c291238b5391834c278] source-hash-c828319753558e25a48ce7808604bcc648f2483d
    # possible first bad commit: [bb138a397a1f29902ce6c69bb161254832081623] source-hash-acf233e2bb259759c9167a32e17fcf13e1f54f6c
    # possible first bad commit: [c2e967de61ee4b1291703af64dac729a8ada79fb] source-hash-17dab5bf8efb3fd676e6854474b199b681d0dc28
Comment 5 Matthew Francis 2014-12-27 15:36:16 UTC
The below commit seems to be where the behaviour changed

Adding a Cc: to muthusuba@gmail.com. Could you possibly shed any light on this one? Thanks

commit aa822c44b758fe312a3a052f890f53418adc5f6b
Author: Muthu Subramanian <sumuthu@collabora.com>
Date:   Tue Dec 10 17:20:34 2013 +0530

    n#753460: Copying slides having same master page name.
    
    Has part feature of getting hashes of SdPages.
    (Misses hashing text, images, etc).
Comment 6 Muthu 2014-12-27 18:40:04 UTC
I am assuming this is fixed now, please?

And a duplicate of bug 85247
Comment 7 Matthew Francis 2014-12-28 02:28:52 UTC
Confirmed that this is fixed on master and a duplicate

*** This bug has been marked as a duplicate of bug 85247 ***
Comment 8 Robinson Tryon (qubit) 2015-12-15 11:03:39 UTC
Migrating Whiteboard tags to Keywords: (bibisected)
[NinjaEdit]
Comment 9 Cecil Rundle 2020-07-11 19:03:07 UTC Comment hidden (spam)