Description: Certain footnotes are only partly rendered (missing top/bottom have of the text) after undo or cut paste Steps to Reproduce: 1. Open attachment 143565 [details] 2. CTRL+A 3. CTRL+X 4. CTRL+Z -> Scroll through the document.. there is no fixed position.. but a lot of footnotes are off 5. CTRL+N 6. CTRL+V -> Look again for broken footnotes Actual Results: Footnote only partly visible Expected Results: Readable Reproducible: Always User Profile Reset: No Additional Info: Version: 7.2.0.0.alpha0+ (x64) Build ID: f2171af6ce3516598d9f8bac8294025a21a5b1a2 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL
Also in Version: 6.2.4.0.0+ Build ID: 5c5eab3522368d6baa7ab6ef1b6c9f5eaaab4fad CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; Locale: nl-NL (nl_NL); UI-Language: en-US Calc: CL
Still ok in Version: 6.1.6.3 Build-ID: 5896ab1714085361c45cf540f76f60673dd96a72 CPU-Threads: 4; BS: Windows 6.3; UI-Render: GL; Gebietsschema: nl-NL (nl_NL); Calc: CL
Bisected to author Michael Stahl <Michael.Stahl@cib.de> 2018-08-22 17:09:02 +0200 committer Michael Stahl <Michael.Stahl@cib.de> 2018-09-19 10:18:29 +0200 commit 723728cd358693b8f4bc9d913541aa4479f2bd48 (patch) tree 1ac75a662a46987301ea85d32957eb08f435ffd6 parent 41d8ca9686c7c184f586e99674b443c34bfd4f33 (diff) sw_redlinehide_2: SwUndoDelete This is problematic because of the calls to SplitNode. Ideally we'd want the SplitNode to create merged frames already, but that doesn't seem to be easy to achieve; several problems with this are: 1. the redlines are only restored at the end of UndoImpl 2. even if we store another set of SwRedlineSaveDatas right before the Join (while preventing the first SwRedlineSaveDatas from deleting them), and restore them by passing a closure to SplitNode, there are complaints about empty redlines, and also this case isn't handled properly: f<delete start>o<redline start>o b<redline end>a<redline start>r b<redline end>a<delete end>z So instead, let SplitNode create whatever frames it does, and fix it up at the end manually on the start node's frames. This necessitates delaying the creation of the frames on the moved nodes until the end too. https://cgit.freedesktop.org/libreoffice/core/commit/?id=723728cd358693b8f4bc9d913541aa4479f2bd48
I could not reproduce this on Version 7.2.0.0.alpha0+ (x64), though on different OS version: Steps to Reproduce: 1. Open attachment above 2. CTRL+A 3. CTRL+X 4. CTRL+Z -> Scroll through the document.. *ALL footnotes are there in full rendering (I have checked ALL pages)* 5. Open attachment above 6. CTRL+A 7. CTRL+X 8. CTRL+N 9. CTRL+V -> Look again for broken footnotes * NO broken footnotes. ALL footnotes are there in full rendering (I have checked ALL pages)* Additional Info: Version: 7.2.0.0.alpha0+ (x64) Build ID: 9f9798f07f0b56ae474f31ded671cc8da598d244 CPU threads: 16; OS: Windows 10.0 Build 18363; UI render: Skia/Vulkan; VCL: win Locale: ar-IQ (ar_IQ); UI: ar-SA Calc: CL Maybe you could define one or two notes by number to let me check them specifically.
Couldn't reproduce the bug Version: 7.4.0.0.alpha0+ Build ID: d951a054445ad3741d678f422a5b605feae06a6b CPU threads: 4; OS: Linux 5.11; UI render: default; VCL: gtk3 Locale: en-IN (en_IN); UI: en-US Calc: threaded
Created attachment 178017 [details] The origial document and its copy to a new document Repro in: Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: 2f4f4cbeb8e50081d607b86b0475b93971c40ab8 CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: hu-HU (hu_HU.UTF-8); UI: en-US Calc: threaded but only after copy&paste to a new document.
Adding CC to: Michael Stahl
Michael Stahl committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/86081afc3021fa0ae6c2b32d11b4b20cc8a190a3 tdf#139687 sw: invalidate text frame in footnote when moving it It will be available in 7.4.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.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/c79bf7865bff4e88cc201357370d8faeef8e6ad9 (related: tdf#139687) sw: ignore following footnotes in SwTextFrameBreak It will be available in 7.4.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.
could reproduce this via copy/paste and SAL_USE_VCLPLUGIN=kf5, not with gtk3. fixed on master. after Undo there was another problem where the pagination was different than before.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-7-3": https://git.libreoffice.org/core/commit/3d8533cb894614394f1ecf05b3d6dc60f3bf6dd6 tdf#139687 sw: invalidate text frame in footnote when moving it It will be available in 7.3.3. 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.
Verified in Version: 7.5.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 4e2ce2a460458f17ee4360c45a2da2fc4b4d753e CPU threads: 14; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: en-US (hu_HU); UI: en-US Calc: threaded Footnotes are visible after cut - undo or cut - paste.