Created attachment 92186 [details] Single sheet with some conditional formatting. 58484 Problem description: Creating, moving, and deleting a (empty) sheet, then saving appears to corrupt conditional formatting formulas. Steps to reproduce: 1. Open supplied spreadsheet. 2. Note one red cell. This is correct, as image 1 shows. 3. Create a new sheet by clicking the green plus arrow. 4. Click-drag Sheet2 tab to position 1, so that Sheet2 is the first sheet, and Data is the second sheet. 5. Right-click on the Sheet2 tab and choose "Delete" from the context menu. 6. Close window/exit Libreoffice, so that you're prompted with "Save your work?" dialog before exiting. 7. Click save. 8. Reopen the spreadsheet, and note two red cells that are now incorrect. Current behavior: A seemingly innocuous operation (adding, then removing an empty sheet) corrupts the conditional formatting on another sheet. Expected behavior: The conditional formatting should not get corrupted. Operating System: Ubuntu Version: 4.1.3.2 release
Created attachment 92187 [details] What sheet should look like.
Created attachment 92188 [details] Conditional formatting formulas before corruption
Created attachment 92189 [details] Making a new sheet
Created attachment 92190 [details] Move new Sheet2 to first tab position
Created attachment 92191 [details] Right-click Sheet2 and select Delete
Created attachment 92192 [details] Close window and click yes on "Save?" prompt
Created attachment 92193 [details] See new red cells that should not be there
Created attachment 92194 [details] Now corrupted conditional formatting formulas
Comment on attachment 92186 [details] Single sheet with some conditional formatting. Updating mime type.
This is potentially related or a duplicate of one of these bugs: Bug 48360 Bug 54464 Bug 54842 Bug 58484 Maybe not, but perhaps they can some context to track down the error, if needs be.
Partly reproduced with LibO 4.2.0.2 on Win7 : - after step 5, the two red (C29:D29) cells are incorrect, - after step 8, there are no more conditional formating. Thus related to bug 54464 and bug 58484 (not fully resolved ? regression ?).
Thank you for reporting this issue! I have been able to confirm the issue on: Version: 4.2.0.3 rc Platform: Ubuntu Linux 13.04 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + As I've been able to confirm this problem I am marking as: New (confirmed) Major - loss of data High Markus - any thoughts on this one? Instructions are really clear and I can reproduce on last RC + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + LibreOffice is powered by a team of volunteers, every bug is confirmed (triaged) by human beings who mostly give their time for free. We invite you to join our triaging by checking out this link: https://wiki.documentfoundation.org/QA/BugTriage and join us on freenode at #libreoffice-qa There are also other ways to get involved including with marketing, UX, documentation, and of course developing - http://www.libreoffice.org/get-help/mailing-lists/. Lastly, good bug reports help tremendously in making the process go smoother, please always provide reproducible steps (even if it seems easy) and attach any and all relevant material
(In reply to comment #0) > 8. Reopen the spreadsheet, and note two red cells that are now incorrect. No longer reproducible under GNU/Linux using v4.3.0.4 Build ID: 62ad5818884a2fc2e5780dd45466868d41009ec0. Original single red cell displays as expected after described actions. Perhaps fixed at some point?
(In reply to Owen Genat from comment #13) > (In reply to comment #0) > > 8. Reopen the spreadsheet, and note two red cells that are now incorrect. > > No longer reproducible under GNU/Linux using v4.3.0.4 Build ID: > 62ad5818884a2fc2e5780dd45466868d41009ec0. Original single red cell displays > as expected after described actions. Perhaps fixed at some point? Reproducible again under GNU/Linux using v4.3.2.2 Build ID: edfb5295ba211bd31ad47d0bad0118690f76407d.
*** Bug 99378 has been marked as a duplicate of this bug. ***
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.2.7 or 5.3.3 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170522
This is still present It was also working in LO 3.3, so this is a regression Version: 6.4.0.0.alpha1+ Build ID: 80109586e6cb6d3e2e0a53a9079c3125ec9b8368 CPU threads: 4; OS: Mac OS X 10.14.6; UI render: default; VCL: osx; Locale: en-US (en_US.UTF-8); UI-Language: en-US Calc: threaded
Good catch! Bibisected to the followiing commit using repo bibisect-41max. https://cgit.freedesktop.org/libreoffice/core/commit/?id=9261c0bf6ecf6633a5577879f003edfcb569f4d7 author Markus Mohrhard <markus.mohrhard@googlemail.com> 2013-03-24 05:09:08 +0100 committer Markus Mohrhard <markus.mohrhard@googlemail.com> 2013-03-24 05:14:18 +0100 URM_INSDEL we need to update the src position, fdo#62206
Dear Kevin Hunter, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
This is still present Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: 583185235389b55d6cfffac3067c0e1ccb2852b1 CPU threads: 10; OS: Mac OS X 10.16; UI render: Skia/Raster; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Fix is posted at https://gerrit.libreoffice.org/c/core/+/160234.
Created attachment 191604 [details] A single formula and a single conditional formatting The attachment has a simplest case, that allows to see the difference in processing. B1 has a formula "=A1"; and also it has a conditional formatting "if value is equal A1 ...". So both reference the same cell (i.e., have relative reference "same tab, column -1, same row"). Put breakpoint to adjustSingleRefOnDeletedTab, do steps from comment 0 (just with this attachment), and see how the *two* invocations of adjustSingleRefOnDeletedTab - first for ScConditionalEntry, and second for ScFormulaCell in call stack - differ in the value of *rOldPos* argument. For ScFormulaCell case, it has tab 1, while for ScConditionalEntry case, it has tab 0. It shows, that the wrong tab is passed to the function in one case; so the function has no chance to do the right job. The fix should focus on finding, why doesn't conditional formatting tab data update on Sheet2 move.
(In reply to Mike Kaganski from comment #22) > The fix should focus on finding, why doesn't conditional formatting tab data > update on Sheet2 move. You were right, there was a better way of doing this that matches what you would expect. I've updated the linked fix with a new patchset.
Matt K committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/0ba4e0483bacd698a227d0d18422fc6a08055c28 tdf#73678 Prevent conditional formatting from being lost in Calc It will be available in 24.8.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.
Matt K committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/5653238332deac00affa4fa913354b3c8384dab9 tdf#73678 Prevent conditional formatting from being lost in Calc It will be available in 24.2.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.