Description: Delete one of both paragraph below a table deletes the table Steps to Reproduce: 1. Open the attached file 2. Toggle formatting marks on 3. Delete one of both paragraph markers. Actual Results: Table disappears Expected Results: Not so 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: default; VCL: win Locale: nl-NL (nl_NL); UI: nl-NL Calc: CL
Created attachment 168792 [details] Example file
Found in Version: 6.4.0.0.beta1+ (x64) Build ID: 20be5cd0bdc57d812bf34a2debfe48caa51de881 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win; Locale: nl-NL (nl_NL); UI-Language: en-US Calc: CL but not in 6.2.9
Created attachment 168794 [details] Bibisect log Bisected to: author Michael Stahl <Michael.Stahl@cib.de> 2019-12-05 16:49:33 +0100 committer Michael Stahl <michael.stahl@cib.de> 2019-12-06 13:26:32 +0100 commit 91b2325808a75174f284c48c8b8afc118fad74e4 (patch) tree d456e57e6d0d0532592030cb0d3d20585b8fe7a4 parent 6ed12ab2d0742f86ce25defec3c776562dbfad9a (diff) tdf#121300 sw: consistent fly at-pargraph selection As a follow-up to commit 28b77c89dfcafae82cf2a6d85731b643ff9290e5, add IsSelectFrameAnchoredAtPara() function and use it to harmonize at-para fly selection across all relevant operations: * CopyImpl: - it had a pre-existing bugs that would lose a fly anchored to the 2nd (1st fully selected) node of a redline - remove a bunch of code for finding the last node of the body content, which doesn't matter for the remaining at-fly checks - flys that already existed at the insert position need to have their anchors corrected * DeleteRange: - get rid of the bDelFwrd checks * MoveRange: - the ALLFLYS flag would be obsoleted by the new selection, were it not for the writerfiler "special hack", see below * also adapt A11y and UI selection, SwRootFrame::CalcFrameRects() The selection behavior is changed: * the bDelFwrd case is quite odd, some code was checking whether a deletion was "forward" or "backward" and removing only the flys at the point node while retaining the flys at the mark node; this worked in a very non-obvious way relying on sw_GetJoinFlags actually calling Exchange() on the cursor, and then SwUndoDelete stored it in m_bJoinNext, but it turns out that only SwUndoMove also has a m_bJoinNext and it's dead, and no other Undo has such a flag, so this only worked for "delete". It's not obvious what the value of this is, let's just ignore the "direction". * Selections exclude the start and end position except if it's a fully selected node or at the start or end of a section (i.e. Ctrl+A should also select every at-para fly). * An exception is made in case the selection looks like it's a backspace/delete joining 2 paragraphs; flys are not deleted in that case because it seemed annoying (and as it happens, Word does not appear to delete flys in that case), particularly if both of the nodes are already empty. This is done with a heuristic, it's conceivable to pass down some flag from DelLeft()/DelRight() but probably this is good enough. A special hack is needed to keep writerfilter happy for now; it likes to anchor flys at nodes which it then deletes in RemoveLastParagraph(), which likely could be improved there. The ALLFLYS usage in SwRangeRedline::MoveFromSection() could be removed (because the end-of-section check already handles the case) except for this, because it turns out that the ODF import runs SetRedlineFlags with a temporarily reset IsInXMLImport() flag because of its effect in thints.cxx, so during the move IsSelectFrameAnchoredAtPara() can't check it. tdf#108124 scenario works better, now everything that's selected is both copied and deleted. Fixes the problem where an at-para fly at the 2nd node of a redline where the 1st node is partially deleted was lost on ODF export. https://cgit.freedesktop.org/libreoffice/core/commit/?id=91b2325808a75174f284c48c8b8afc118fad74e4
Adding CC: to Michael Stahl UNCONFIRMED for now.. but I'm assume I'm right
Thank you for reporting the bug. I can confirm the bug present in, Version: 7.0.3.1 (x64) Build ID: d7547858d014d4cf69878db179d326fc3483e082 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL Version: 7.2.0.0.alpha0+ (x64) Build ID: 761a672d62df1891b9f4f367a499b220ab2b33fa CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL
the description is a duplicate of bug 133957; there is another issue with the fix for that where the Undo puts the anchor on the wrong paragraph, that will be fixed in a subsequent commit. incidentally table is a red herring, they're in text frames and that's what's getting deleted.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/12acdce71dd6b6af2c52ba8fa3248d3166418543 (related: tdf#139514) sw: fix Undo of delete with at-para fly 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 "libreoffice-7-3": https://git.libreoffice.org/core/commit/054c248127c78521b4a4e7aacd8936bd54259996 (related: tdf#139514) sw: fix Undo of delete with at-para fly It will be available in 7.3.5. 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.