in Writer, copy a shape w/ text-box and paste it, the result will be 2 unconnected objects, a shape and a text frame. the problem is that in DocumentContentOperationsManager::CopyFlyInFlyImpl(), the SwTextBoxHelper::resetLink(pFormat, aOldContent); removes the RES_CNTNT property that isTextBox() checks to determine it's a text box (it's also required in CopyLayoutFormat()). if (!pShape || pShape->Which() != nType || !pShape->GetAttrSet().HasItem(RES_CNTNT)) return false; it's only restored at the end of the function, when it's too late: SwTextBoxHelper::restoreLinks(aSet, aVecSwFrameFormat, aOldTextBoxes, aOldContent); i don't understand why we need this? reading the git log it looks to me that this caused it: commit 0bcc5b3daebeb2a7d2b5ba132af4745cc6c78cd0 Author: Jan-Marek Glogowski <glogow@fbihome.de> AuthorDate: Fri Jul 22 17:50:52 2016 +0200 Switch isTextBox to use the format pointers This replaces all possible occurences of the text box format maps, which just want to know, if a SwFrameFormat is part of a text box to use the direct lookup via the isTextBox, which is now a cheap call.
forgot to mention: this happens when you copy text in which a textbox is anchored; if you select the textbox and copy it then it doesn't go via that function and there's a SwUiWriterTest::testFdo82191(); i noticed because i wanted to remove that code but that's futile anyway because it's the only way to copy the horrible at-page flys.
Without sample file bit hard to confirm or track..
The original doc model I added was that a draw format and a fly format is linked together to form a textbox in case they both have RES_CNTNT that point to the same content. This has the nice property that those node indexes are automatically updated in many cases, unlike raw pointers. Jan-Marek noticed some perf problems with this, since in case you have lots of textboxes, then looking up all these pairs is O(N^2) (where N is the number of frame formats in the special frame format array). So he added those raw pointers in the SwFrameFormat class, to have faster way/cache to jump to the "other" frame format (if there is any). Is it possible that at some stage we update RES_CNTNT but not these newer pointers? The reset/restoreLinks() code is only relevant for linked text frames. I.e. imagine some corner case that you have 2 rounded rectangles and the text content flows from the 1st to the 2nd one. Then you need the 2 draw formats for the rounded corners, but the 2 fly formats will be linked fly frames. Hope this helps.
the problem in resetLinks is this: >694 pShape->ResetFormatAttr(RES_CNTNT);
Michael Stahl committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/10ae7ba661dff57a7d08174792565ec5e33fae9b tdf#135412 tdf#135888 sw: fix copying of linked text-boxes It will be available in 7.1.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
turns out this was the root cause of the other bug i was trying to fix -> fixed on master
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-7-0": https://git.libreoffice.org/core/commit/9ae30972319a046d0b8176e3f0bc85f8ae976c93 tdf#135412 tdf#135888 sw: fix copying of linked text-boxes It will be available in 7.0.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-6-4": https://git.libreoffice.org/core/commit/8934e31f53274a5e288340c9f756aac5f931eba4 tdf#135412 tdf#135888 sw: fix copying of linked text-boxes It will be available in 6.4.7. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.