| Summary: | copy and paste of a slide results in a blue slide in presentation mode | ||
|---|---|---|---|
| Product: | LibreOffice | Reporter: | Caolán McNamara <caolan.mcnamara> |
| Component: | Impress | Assignee: | Muthu <muthu.subramanian.karunanidhi> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | muthusuba, void |
| Priority: | medium | ||
| Version: | 4.4.0.0.alpha0+ Master | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | target:4.4.0 target:4.3.5 | ||
| Crash report or crash signature: | Regression By: | ||
| Attachments: | Patch for review | ||
|
Description
Caolán McNamara
2014-10-20 15:49:30 UTC
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 |