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.
I have found this bug on two independent systems (Debian and Ubuntu)
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.
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.
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
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).
I am assuming this is fixed now, please? And a duplicate of bug 85247
Confirmed that this is fixed on master and a duplicate *** This bug has been marked as a duplicate of bug 85247 ***
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.