Description: Tracking changes items appear while not being shown at all Steps to Reproduce: 1. Open the attached file 2. Select the content on first page 3. Delete using delete or backspace 4. Delete the empty bullet (arrow) on the now first page -> by pressing backspace multiple times 5. Press Save 6. Hold CTRL+Z Actual Results: Arrow reappears after save (in red) After pressing undo multiple items in red Expected Results: Should not be so Reproducible: Always User Profile Reset: No Additional Info: Version: 7.1.0.0.alpha0+ (x64) Build ID: c48e4d795e37f23b71d647247590807ab9e52223 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
Created attachment 162936 [details] Example file
Created attachment 162937 [details] Screencast
Source file: attachment 162927 [details] bug 134746 because older (6.2) versions of LibreOffice render the sample file differently
Also in Version: 4.3.7.2 Build ID: 8a35821d8636a03b8bf4e15b48f59794652c68ba
Lowest priority because minor issue with strange file of unknown origin that has bigger issues: crash on content delete, content remains after delete, track not shown.. This bug is not worth reporting nor confirming. Only the crash.
*** This bug has been marked as a duplicate of bug 134773 ***
(In reply to Timur from comment #5) > Lowest priority because minor issue with strange file of unknown origin that > has bigger issues: crash on content delete, content remains after delete, > track not shown.. 1) Strange file .. What makes it a strange file? 2) Unknown origin (see comment 3) 3) Content remains after delete? They table? Or something else, be specific please 4) Crash on content delete (solved) See bug 134770 5) Track not shown.. What do you mean? And also don't add it as duplicate of bug 134773. This only suggests you're not understanding the issue or the difference between both. Or ending up making a mess with duplicates. Or you want to close it for other reason not explicitly stated, but even then don't use duplicate if it isn't
Bibisected with linux-64-6.3 to https://git.libreoffice.org/core/commit/32902f66e7749b2d06d13f50416be5323a0c0ea9 sw_redlinehide: make layout based Show/Hide mode the default Adding Cc: to Michael Stahl The commit is referenced in multiple regressions, please see query: https://bugs.documentfoundation.org/buglist.cgi?keywords=regression%2C%20&keywords_type=allwords&list_id=1249164&longdesc=32902f66e7749b2d06d13f50416be5323a0c0ea9&longdesc_type=allwordssubstr&query_format=advanced
(In reply to Buovjaga from comment #8) > Bibisected with linux-64-6.3 to > https://git.libreoffice.org/core/commit/ > 32902f66e7749b2d06d13f50416be5323a0c0ea9 > sw_redlinehide: make layout based Show/Hide mode the default > > Adding Cc: to Michael Stahl > > The commit is referenced in multiple regressions, please see query: > https://bugs.documentfoundation.org/buglist. > cgi?keywords=regression%2C%20&keywords_type=allwords&list_id=1249164&longdesc > =32902f66e7749b2d06d13f50416be5323a0c0ea9&longdesc_type=allwordssubstr&query_ > format=advanced Needs another round of bibisecting with environment variable SW_REDLINEHIDE
merged para is from node 93 to 254, 254 is pParaPropsNode - both before and after save. the difference is that before save node 254 had: 72 = { <SfxStringItem> = { <CntUnencodedStringItem> = { <SfxPoolItem> = { _vptr.SfxPoolItem = 0x7f7e7a6b3940 <vtable for SwNumRuleItem+16>, m_nRefCount = 3, m_nWhich = 72, m_nKind = SfxItemKind::NONE }, members of CntUnencodedStringItem: m_aValue = "" }, <No data fields>}, <No data fields>}, while after save: 72 = { <SfxStringItem> = { <CntUnencodedStringItem> = { <SfxPoolItem> = { _vptr.SfxPoolItem = 0x7f7e7a6b3940 <vtable for SwNumRuleItem+16>, m_nRefCount = 92, m_nWhich = 72, m_nKind = SfxItemKind::NONE }, members of CntUnencodedStringItem: m_aValue = "Bullet " }, <No data fields>}, <No data fields>}, 79 = { <CntUInt16Item> = { <SfxPoolItem> = { _vptr.SfxPoolItem = 0x7f7ec29d0680 <vtable for SfxUInt16Item+16>, m_nRefCount = 80, m_nWhich = 79, m_nKind = SfxItemKind::NONE }, members of CntUInt16Item: m_nValue = 2 }, <No data fields>}, 82 = { <CntUnencodedStringItem> = { <SfxPoolItem> = { _vptr.SfxPoolItem = 0x7f7ec29d2398 <vtable for SfxStringItem+16>, m_nRefCount = 93, m_nWhich = 82, m_nKind = SfxItemKind::NONE }, members of CntUnencodedStringItem: m_aValue = "list2998949076" }, <No data fields>}, 83 = { <SfxPoolItem> = { _vptr.SfxPoolItem = 0x7f7ec29d0710 <vtable for SfxInt16Item+16>, m_nRefCount = 75, m_nWhich = 83, m_nKind = SfxItemKind::NONE }, members of SfxInt16Item: m_nValue = 1 }, 92 = { <SfxPoolItem> = { _vptr.SfxPoolItem = 0x7f7ec4dac8d8 <vtable for SvxULSpaceItem+16>, m_nRefCount = 113, m_nWhich = 92, m_nKind = SfxItemKind::NONE }, members of SvxULSpaceItem: nUpper = 200, nLower = 120, bContext = false, nPropUpper = 100, nPropLower = 100 }, ... apparently these items were on pFirstNode before saving, then moving the redlines merged first and last paragraph, then moving redlines back didn't fix it. hmm not obvious what to do about this.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/3707c0b4ff683ac6f0942a176ebcb8d824b567ee tdf#134759 sw: clear items in SwAttrSet::CopyToModify() It will be available in 7.5.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-4": https://git.libreoffice.org/core/commit/cdf48e57da6b8a6a5eb4131340fa2c14be135714 tdf#134759 sw: clear items in SwAttrSet::CopyToModify() It will be available in 7.4.0.0.beta2. 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/81273c65dd9cec5acd9464b9041f452a5481e10e tdf#134759 sw: do CopyToModify() for both start and end node It will be available in 7.5.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.
i think i managed to fix something here, but it's rather tricky to know for sure. the first problem was that when the redlines are moved for both Show and Hide, the existing paragraph properties at the target weren't cleared. the second problem was that when the redlines are moved for Show, the paragraph properties were applied only to the start paragraph, not to the end paragraph. of course these problems have always existed, it just wasn't obvious previously when you could edit the document in the "hidden" state.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-7-4": https://git.libreoffice.org/core/commit/c0008da4f9884c92b8403823c935750d59b9552b tdf#134759 sw: do CopyToModify() for both start and end node It will be available in 7.4.0.0.beta2. 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 Undo after save does not change the formatting.