Steps: 1. Open Calc 2. Select several columns and rows 3. Apply some formatting, like yellow background or all borders 4. Undo Result: Undoing the first formatting action only works for column A, formatting remains for other columns. All further formatting actions undo as expected. Reproduced from: Version: 7.4.5.1 / LibreOffice Community Build ID: 9c0871452b3918c1019dde9bfac75448afc4b57f CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded To: Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 288c0920a8475f9f2c537212e04aa7649192ad8c CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Also on Windows 10, with 7.5.1.2. Bibisected with linux-64-7.4 repo to first bad commit d14c498f036bf5f6f99503115eeec2a72bd1ba83 which points to core commit: commit 9e2d48b9e04f7ea895fb095699c32ed8a44eb129 author Luboš Luňák <l.lunak@collabora.com> Wed Mar 30 11:58:04 2022 +0200 committer Luboš Luňák <l.lunak@collabora.com> Thu Apr 28 05:51:53 2022 +0200 tree e7762a098c6dc066d9dc73888bd3c992cbb13490 parent ee57936475064b409565490022f414220656e12c reduce Calc's INITIALCOLCOUNT to 1 Columns should be dynamically allocated on demand, so there should be theoretically no good reason to allocate 64 initially. In practice doing so hides all places that do not allocate columns as needed. Change-Id: I8b46ecc97852ed23369e720f50f3266c48440435 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133311 Luboš, any chance you could have a look?
Reproducible. Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 687b950702c49c90cff9a43655ea97a0343799a0 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded Jumbo
*** Bug 154066 has been marked as a duplicate of this bug. ***
Please note that this is not just for column A. See STR in bug 154066 comment 2.
This problem exists when upgrading the LO version Данная проблема существует при обновлении версии LO
(In reply to Roman from comment #4) > This problem exists when upgrading the LO version Please always state which version you used. I can still reproduce in a recent master build: Version: 7.6.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 1349f140fcc49e5da78482ca3db09663ccdae0a9 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded
Version: 7.5.3.2 (X86_64) / LibreOffice Community Build ID: 9f56dff12ba03b9acd7730a5a481eea045e468f3 CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: default; VCL: win Locale: ru-RU (ru_RU); UI: ru-RU Calc: CL threaded The problem is urgent Проблема актуальна
Still repro as of today's 7.6.alpha.
Increasing the importance as Luboš is not active.
Still reproducible in Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: dcd46a0ff9e3e78fc53ce21e7adf314f6e4a033b CPU threads: 8; OS: Linux 6.1; UI render: default; VCL: gtk3 Locale: es-ES (es_ES.UTF-8); UI: en-US Calc: threaded @Julien, since you fixed bug 158551 I thought you might be interested in this one as well...
I can reproduce with: Version: 7.4.7.2 / LibreOffice Community Build ID: 40(Build:2) CPU threads: 4; OS: Linux 6.1; UI render: default; VCL: gtk3 Locale: de-DE (de_DE.UTF-8); UI: de-DE Debian package version: 4:7.4.7-1+deb12u1 Calc: threaded BUT CANNOT reproduce with: Version: 7.6.4.1 (AARCH64) / LibreOffice Community Build ID: e19e193f88cd6c0525a17fb7a176ed8e6a3e2aa1 CPU threads: 4; OS: Linux 6.1; UI render: default; VCL: gtk3 Locale: de-DE (de_DE.UTF-8); UI: en-US Flatpak Calc: threaded
(In reply to Xisco Faulí from comment #9) > Still reproducible in > > Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community > Build ID: dcd46a0ff9e3e78fc53ce21e7adf314f6e4a033b > CPU threads: 8; OS: Linux 6.1; UI render: default; VCL: gtk3 > Locale: es-ES (es_ES.UTF-8); UI: en-US > Calc: threaded > > @Julien, since you fixed bug 158551 I thought you might be interested in > this one as well... With a crash, I know where to begin to search but when there's no crash, no idea where to search. Moreover grepping "undo" retrieves too many results. => uncc myself.
Hi Noel, since you fixed many issues related to bug 50916 I thought you might be interested in this issue
In case it helps, if https://opengrok.libreoffice.org/xref/core/sc/source/ui/view/viewfunc.cxx?r=fd11b632#1335 is deleted, then yello background is not applied. I think it can be a good starting point for debugging
Hi Mike, I thought you might be interested in this issue... if not, feel free to remove yourself from CC and sorry for adding you. I'm just trying to find someone to fix it. I believe this should be easy to fix for someone familiar with the code, similar to 3282756b7984457c79044d08127a4def64905979. I added a code pointer in comment 13 in case it helps
(In reply to Xisco Faulí from comment #14) Without looking into the code: 1. If prior to step 2 in comment 0, you put anything into the columns that you will select later, then the rest will work as expected. Indeed, the bibisected commit 9e2d48b9e04f7ea895fb095699c32ed8a44eb129 suggests just that. 2. If you do this modified sequence: 1. Open Calc 2. Select columns A:C 3. Apply yellow background 4. Select columns A:D 5. Apply red background 6. Undo then the "Undo" step will undo the change in columns A:C, which suggests that step 3 created the structures needed for the Undo, and later edits there work as expected. The problem seems to be that there is no undo entry for applying format to *previously unallocated* columns. They are created with the new settings, and not "unallocated" on Undo (not unallocating them is likely OK itself, but the code allocating them should add something to the current Undo action). Sorry, can't work on this at the moment; hope these general ideas could be helpful (first of all, no idea if they are even correct).
Note also, that in 7.3, even selecting columns A:CA (i.e., more than 64 columns) in step 2 didn't produce the same problem. The bibisected commit 9e2d48b9e04f7ea895fb095699c32ed8a44eb129 suggests that it only modified a single constant, and prior to it, selecting A:CA should still produce the same problem for columns after BM. My strong suspicion is that there was some previous commit, that was the actual regression (with columns after 64) - which could be bibisected. Another unlikely explanation could be, that the Undo code somehow checks itself, if it works with columns >64, and does some magic then (which was useful back then, when INITIALCOLCOUNT was 64). But then, it would still work OK in current versions, when selecting A:CA, which is not the case.
(In reply to Mike Kaganski from comment #16) > Note also, that in 7.3, even selecting columns A:CA (i.e., more than 64 > columns) in step 2 didn't produce the same problem. The bibisected commit > 9e2d48b9e04f7ea895fb095699c32ed8a44eb129 suggests that it only modified a > single constant, and prior to it, selecting A:CA should still produce the > same problem for columns after BM. > > My strong suspicion is that there was some previous commit, that was the > actual regression (with columns after 64) - which could be bibisected. Oh, you are right. The real commit introduced this issue was author Luboš Luňák <l.lunak@collabora.com> 2022-02-16 13:19:29 +0100 committer Luboš Luňák <l.lunak@collabora.com> 2022-02-16 21:37:36 +0100 commit 823eb92025853d120c17790d1c8efde59f033c69 (patch) tree 8e4d0a07d952b73850f6c4b2241b5ed80a2978aa parent a717029e217621482ef799731f945090c6d6be4b (diff) do not allocate columns in ScTable::GetPattern() https://gerrit.libreoffice.org/c/core/+/161118 should fix it. Review appreciated
https://gerrit.libreoffice.org/c/core/+/161127
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/36b7ae36715cbf47b451e41e47aebe28cf594bd8 tdf#154044: Also store default column data, when copying to Undo document 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.
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/4966d3a344c18d8ef47613fbd6c1b1b1e90eb8f3 tdf#154044: Also store default column data, when copying to Undo document 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.
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-7-6": https://git.libreoffice.org/core/commit/877b7cdbfd98188872c983bb8404e5627a521360 tdf#154044: Also store default column data, when copying to Undo document It will be available in 7.6.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.
Thanks Mike! Fix verified for: Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 960e37af28807ed1b376e26c4504ab755a81dfd5 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded