Description: Spreadsheet containing only empty cells of different background colours only saves the background colours of columns A to BL when saving as ods (haven't tried other formats). Columns past BL lose their background colour (resets to 'No Fill') Steps to Reproduce: 1. Create spreadsheet with no cell contents other than different background colours. Make sure to go past column BL 2. Save as ods 3. Close Calc and reopen 4. Open ods file 5. Observe loss of background colour information Actual Results: 'No Fill' cells after column BL Expected Results: All information gets saved Reproducible: Always User Profile Reset: No Additional Info: Version: 6.3.5.2 (x64) Build ID: dd0751754f11728f69b42ee2af66670068624673 CPU threads: 12; OS: Windows 10.0; UI render: default; VCL: win; Locale: en-CA (en_CA); UI-Language: en-US Calc: CL
Created attachment 161205 [details] Image demonstrating cell bg colour cutoff
Created attachment 161220 [details] Sample file Works fine for me. Versión: 6.4.4.2 (x64) Id. de compilación: 3d775be2011f3886db32dfd395a6a6d1ca2630ff Subprocs. CPU: 4; SO: Windows 10.0 Build 19608; Repres. IU: GL; VCL: win; Configuración regional: es-ES (es_ES); Idioma de IU: es-ES Calc: CL
Hello, I changed streams and upgraded to 6.4 and the issue persists. Version: 6.4.4.2 (x64) Build ID: 3d775be2011f3886db32dfd395a6a6d1ca2630ff CPU threads: 12; OS: Windows 10.0 Build 17763; UI render: default; VCL: win; Locale: en-CA (en_CA); UI-Language: en-US Calc: CL What more information can I provide to help describe this issue?
I tried with your attached test file and it indeed does not lose the background colour information. I will try more to isolate the cause of the issue.
Created attachment 161238 [details] Demonstrating working bgcolor, 6.4 To create: click '1' to highlight whole row, press fill button. Save, close and reload. Bgcolor is fine.
Created attachment 161239 [details] Demonstrating broken bgcolor, 6.4 To recreate: 1. press '1' to highlight whole row, press fill button. 2. press '3' to highlight whole row, press fill button. 3. Save, close, reload Observe cutoff at BL
I've attached two ods files which seem to demonstrate where the issue starts happening for me. (Filling rows 1 and 2 doesn't display this behaviour) I hope these are helpful. Please let me know if there is any further information I could provide (logs &c)
Thanks for reporting Can't reproduce in Version: 7.0.0.0.alpha1+ Build ID: 0677d46bcc56c1f6c27b9331662990b38fd452d6 CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: kf5; Locale: en-US (en_US.UTF-8); UI: en-US TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2020-05-21_12:54:11 Calc: CL and Version: 6.4.2.2 Build ID: 1:6.4.2-0ubuntu3 CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: kf5; Locale: en-US (en_US.UTF-8); UI-Language: en-US Calc: threaded
Confirmed, seems the issue happens when a row without background is between. Background for rows 2 and 3 it's reloaded fine Background for rows 2,3 and 5 it's lost from column BL. Versión: 6.4.4.2 (x64) Id. de compilación: 3d775be2011f3886db32dfd395a6a6d1ca2630ff Subprocs. CPU: 4; SO: Windows 10.0 Build 19608; Repres. IU: GL; VCL: win; Configuración regional: es-ES (es_ES); Idioma de IU: es-ES Calc: CL not inherited works with: LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4
*** Bug 136522 has been marked as a duplicate of this bug. ***
With 6.4 and 7.0, bug is easily reproducible, first save of background cells after column BL truncates the background. With 7.0 latest and 7.1+ master, bug is different: additional row of the same background color makes that color disappear after BL column. Steps 1. add background (yellow is always reproducible) to cells before and after BL column, save and reopen, see all fine 2. optional: skip one row add 2nd color, maybe 3rd color..., just once, save, reopen, fine 3. skip at least one row and add additional row of any of those colors. save, reopen, see just those 2 rows missing background after BL So, this is improvement, but still wrong. Bibisect would be helpful, and search for existing bug.
Easier way to find the change for bibisect with 7.0 repo: save with master 7.1+ ODS with single row where background stretches after BL and just see on fileopen that one row is truncated in older LO and not in newer LO. commit 4405d64d9e17dc1e1d7ae976db7706a330c9086f Author: Jenkins Build User <tdf@pollux.tdf> Date: Wed Jan 15 09:37:55 2020 +0100 source bf17db716f4ecaf28c2a0797bf90c9b0731015d6 previous source c2ca2219ef821d87fe499ddc2f6cf9e69c8d4828 author Noel Grandin <noel.grandin@collabora.co.uk> 2020-01-15 09:25:23 +0200 committer Noel Grandin <noel.grandin@collabora.co.uk> 2020-01-15 09:25:26 +0100 commit bf17db716f4ecaf28c2a0797bf90c9b0731015d6 (patch) tree 0cb7828c8eb199193d78288e3257f7b63ac26ea3 parent c2ca2219ef821d87fe499ddc2f6cf9e69c8d4828 (diff) tdf#129393 Calc: cannot format whole row of unprotected cells This commit improved one row issue, but multiple rows is still wrong. Since this is a fix for regression itself, I also checked LO 6.2 before bug 125254, at first it behaved better. Finally, I don't have a definite conclusion. Seems that if you test enough, you will have truncated background after BL or missing all background in the last marked row, even in LO master 7.1+ or in LO 6.2. Adding Noel to CC.
Created attachment 165222 [details] test file with different background color even after BL 3 colors different, 1 or 2 rows left blank, all work after BL column.
(In reply to Julien Nabet from comment #13) > Created attachment 165222 [details] > test file with different background color even after BL > > 3 colors different, 1 or 2 rows left blank, all work after BL column. Try single row color. Definitely seen with 2nd yellow background row.
(In reply to Timur from comment #14) > (In reply to Julien Nabet from comment #13) > > Created attachment 165222 [details] > > test file with different background color even after BL > > > > 3 colors different, 1 or 2 rows left blank, all work after BL column. > Try single row color. Definitely seen with 2nd yellow background row. Ok I could reproduce this but it's a bit tricky since I could reproduce this with yellow not with indigo for example.
Steps to reproduce: 1. Open Calc. 2. Select A2:JA2 and change the background color 3. Select A4:JA4 and change the background color 4. Save and close 5. Reopen
(In reply to Xisco Faulí from comment #16) > Steps to reproduce: > 1. Open Calc. > 2. Select A2:JA2 and change the background color > 3. Select A4:JA4 and change the background color > 4. Save and close > 5. Reopen So this is a regression from author Noel Grandin <noel.grandin@collabora.co.uk> 2019-02-01 15:15:16 +0100 committer Mike Kaganski <mike.kaganski@collabora.com> 2019-04-05 13:43:52 +0200 commit 7282014e362a1529a36c88eb308df8ed359c2cfa (patch) tree 2776ad9601f494330076ac58c08554e719c6ab3a parent df30a4515b1303b0891baa53754fa9b3e47e0c02 (diff) tdf#50916 Makes numbers of columns dynamic. Bisected with: bibisect-linux64-6.3 Adding Cc: to Noel Grandin
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/4176beb7ef831152ce92ac3fa31314438635ec2c tdf#133327 fix calc loading background color with many cols It will be available in 7.1.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.
Seems good to me. @floppydiskeater: you may also test with master https://dev-builds.libreoffice.org/daily/master/Win-x86_64@tb77-TDF/current/LibreOfficeDev_7.1.0.0.alpha0_Win_x64.msi (installs separate to your working LO)
Verified in Version: 7.1.0.0.alpha0+ Build ID: 63317c6b5f3330dcbf977f37a9d01eafbc7451c2 CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded @Noel, thanks for fixing this issue!!
Noel Grandin committed a patch related to this issue. It has been pushed to "libreoffice-7-0": https://git.libreoffice.org/core/commit/0ae68cfb76ea38ffefb79eb27e2329475f8bc71b tdf#133327 fix calc loading background color with many cols It will be available in 7.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.
Noel Grandin committed a patch related to this issue. It has been pushed to "libreoffice-6-4": https://git.libreoffice.org/core/commit/ccef162b4c2623029c4c205063099584f9497342 tdf#133327 fix calc loading background color with many cols It will be available in 6.4.7. 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.
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/4d85d2d482f640a4b5d66995e099895cff6f9c77 tdf#133327: sc_subsequent_filters_test: Add unittest It will be available in 7.1.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.
*** Bug 131455 has been marked as a duplicate of this bug. ***
Not understanding this status change (comment 24). The behavior described in bug 131455 is still present when I test on the following: Version: 6.4.7.2 (x64) Build ID: 639b8ac485750d5696d7590a72ef1b496725cfb5 CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: default; VCL: win; Locale: en-US (en_US); UI-Language: en-US Calc: threaded Version: 7.1.0.0.alpha1+ (x64) Build ID: 418c63dff5db2005bbc4dbfc92b56778f89cea8b CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
The behavior present in my comment 25 is no longer being seen. I was seeing the behavior of duplicate bug (131455) initially, but repeating the test several hours later, I could not trigger the bug again. I do not have any idea as to why the result changed without any intervening steps. Sorry if the "false positives" caused any distraction. Much thanks to all of you who have worked on this. Version: 6.4.7.2 (x64) Build ID: 639b8ac485750d5696d7590a72ef1b496725cfb5 CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: default; VCL: win; Locale: en-US (en_US); UI-Language: en-US Calc: threaded