file->new->presentation. Select slide 1 in slide pane, ctrl c, ctrl v. F5 for presentation view and click, second slide is drawn blue. I have bisected this to aa822c44b758fe312a3a052f890f53418adc5f6b 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).
Ouch - seems like the hashing function is broken (?) Assigning this to myself.
I'm not entirely sure. I rather think that the actual template renaming might be going wrong here or something and its the template renaming method, rather than the hash/stringify, which is at fault. I mean there seems to be something rather odd about the "temporary" master which is created in the clipboard not matching the "original" master as well. But where the blue is coming from is baffling.
Blue is coming from the non-existent Default_ master page. Try reassigning the master page for slide 2 and you'll see that Default_ vanishes and all's fine.
So, Impress seems to handle "Default" Master slide really specially :( The initial copy of Master slide (to the buffer) itself seems partial. Adding something like: diff --git a/sd/source/core/drawdoc3.cxx b/sd/source/core/drawdoc3.cxx index c5b6fa9..7171947 100644 --- a/sd/source/core/drawdoc3.cxx +++ b/sd/source/core/drawdoc3.cxx @@ -108,7 +108,7 @@ void InsertBookmarkAsPage_FindDuplicateLayouts::operator()( SdDrawDocument& rDoc if (aTest == aLayout) { - if( bRenameDuplicates && pTestPage->getHash() != pBMMPage->getHash() ) + if( bRenameDuplicates && pTestPage->getHash() != pBMMPage->getHash() && aTest != OUString("Default") ) { pBookmarkDoc->RenameLayoutTemplate( pBMMPage->GetLayoutName(), OUString(pBMMPage->GetName())+=OUString("_") ); aLayout = pBMMPage->GetName(); Fixes the problem, but then I don't like the "Default" hard code. Will update once I find a better fix.
Created attachment 108168 [details] Patch for review
"The initial copy of Master slide (to the buffer) itself seems partial." yeah, so maybe that's the true bug that the master slide in the temporary copied document is somehow busted. I also think there's another bug in InsertBookmarkAsPage_FindDuplicateLayouts::operator in that it loops over all the master documents in the target with the same name and compares to the pBMMPage, but that means it compares against the "Default" notes page and "Default" handout page as well. I imagine it should compare only against the same "kind" of page in there.
(In reply to Caolán McNamara from comment #6) > "The initial copy of Master slide (to the buffer) itself seems partial." > yeah, so maybe that's the true bug that the master slide in the temporary > copied document is somehow busted. Could very well be - But, I am tempted to address this separately - hope that is fine, please? > > I also think there's another bug in > InsertBookmarkAsPage_FindDuplicateLayouts::operator in that it loops over > all the master documents in the target with the same name and compares to > the pBMMPage, but that means it compares against the "Default" notes page > and "Default" handout page as well. I imagine it should compare only against > the same "kind" of page in there. Agreed. Pushing that as well now - I did some tests, but I hope this doesn't cause another regression! Pushed this as: http://cgit.freedesktop.org/libreoffice/core/commit/?id=0bab8aee77cfc2ffdbc6d3ef6a869284bc12dff4
Pushed to -4-3: http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-4-3&id=1e416e9b5b30f9a06114b24284994bc50715e1ba
*** Bug 84643 has been marked as a duplicate of this bug. ***
Marking this fixed