Created attachment 174308 [details] Sample data as plain text When a new file is created with more than 1001 rows and saved as XLSX the rows over 1001 are lost on save. Steps to reproduce: 1. Open the attached text file, it contains numbers 1-1500 in rows 2. Paste all of this as unformatted text into a new Calc file 3. Save as XLSX, reload in Calc or Excel Actual results: Row 1001 is the last one still having contents. Expected results: All rows retained. LibreOffice details: Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 5aac78e5fb241050a86714687e9ff8804588ae3c CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win Locale: hu-HU (hu_HU); UI: hu-HU Calc: CL Additional Information: Bibisected using bibisect-win64-7.2 to: URL: https://cgit.freedesktop.org/libreoffice/core/commit/?id=2bf3e0d00e3bccb5b250642ee0d3fdbe6cae8ecc author Attila Szűcs <szucs.attila3@nisz.hu> 2021-01-27 17:43:43 +0100 committer László Németh <nemeth@numbertext.org> 2021-02-09 16:37:51 +0100 commit 2bf3e0d00e3bccb5b250642ee0d3fdbe6cae8ecc (patch) tdf#104502 sc: skip hidden columns at printing pages Adding CC to: Attila Szűcs Note: this might be related to the fix added to bug 41425 which introduced an 1000 row limit to save rows with formatting but without contents to xlsx. See also bug 46738 for lifting this limit and properly save any number of rows with formatting but without contents to xlsx.
Created attachment 174309 [details] The sample data inserted to Calc
Created attachment 174310 [details] The sample data saved by Calc
Created attachment 174311 [details] Screenshot of the problem in Calc after reloading
Confirmed using LO 7.3.0.0.alpha0+ (c97bdca2d7abf30a99c45192b8f49c5bf76ca035) / Ubuntu.
On pc Debian x86-64 with master sources updated today, I could reproduce this. I don't understand why it happens only when saving in xlsx and not in ods for example. Indeed, I don't see anything specific to xlsx in the quoted patch.
(In reply to Julien Nabet from comment #5) > On pc Debian x86-64 with master sources updated today, I could reproduce > this. > I don't understand why it happens only when saving in xlsx and not in ods > for example. > Indeed, I don't see anything specific to xlsx in the quoted patch. Also happening when exporting to XLS. This is a blocker for 7.2 release
I gave a try here: https://gerrit.libreoffice.org/c/core/+/120552
(In reply to Julien Nabet from comment #7) > I gave a try here: > https://gerrit.libreoffice.org/c/core/+/120552 Hi Julien, Are you comfortable with the patch being submitting to master and then backported to 7.2 and 7.2.0, otherwise, we should go with the revert for now. Either way, the fix or the revert has to be in 7.2.0
(In reply to Xisco Faulí from comment #8) > (In reply to Julien Nabet from comment #7) > > I gave a try here: > > https://gerrit.libreoffice.org/c/core/+/120552 > > Hi Julien, > Are you comfortable with the patch being submitting to master and then > backported to 7.2 and 7.2.0, otherwise, we should go with the revert for > now. Either way, the fix or the revert has to be in 7.2.0 I won't say "quite confortable" since I don't know how it works. I just noticed this: git grep -n bTableAreaVisibleValid sc/inc/table.hxx:238: mutable bool bTableAreaVisibleValid:1; sc/source/core/data/table1.cxx:270: bTableAreaVisibleValid(false), sc/source/core/data/table1.cxx:564: if (!bTableAreaVisibleValid) sc/source/core/data/table1.cxx:567: bTableAreaVisibleValid = true; git grep -n bTableAreaValid sc/inc/table.hxx:237: mutable bool bTableAreaValid:1; sc/source/core/data/table1.cxx:269: bTableAreaValid(false), sc/source/core/data/table1.cxx:554: if (!bTableAreaValid) sc/source/core/data/table1.cxx:557: bTableAreaValid = true; sc/source/core/data/table2.cxx:1527: bTableAreaValid = false; So thought there could be 1 use of "bTableAreaVisibleValid" lacking. Moreover, this var is new from this patch. I can just tell I don't reproduce the pb with this patch. Now we can also wait for Jenkins results and its check tests.
(In reply to Julien Nabet from comment #9) > (In reply to Xisco Faulí from comment #8) > > (In reply to Julien Nabet from comment #7) > > > I gave a try here: > > > https://gerrit.libreoffice.org/c/core/+/120552 > > > > Hi Julien, > > Are you comfortable with the patch being submitting to master and then > > backported to 7.2 and 7.2.0, otherwise, we should go with the revert for > > now. Either way, the fix or the revert has to be in 7.2.0 > > I won't say "quite confortable" since I don't know how it works. > I just noticed this: > git grep -n bTableAreaVisibleValid > sc/inc/table.hxx:238: mutable bool bTableAreaVisibleValid:1; > sc/source/core/data/table1.cxx:270: bTableAreaVisibleValid(false), > sc/source/core/data/table1.cxx:564: if (!bTableAreaVisibleValid) > sc/source/core/data/table1.cxx:567: bTableAreaVisibleValid = true; > > git grep -n bTableAreaValid > sc/inc/table.hxx:237: mutable bool bTableAreaValid:1; > sc/source/core/data/table1.cxx:269: bTableAreaValid(false), > sc/source/core/data/table1.cxx:554: if (!bTableAreaValid) > sc/source/core/data/table1.cxx:557: bTableAreaValid = true; > sc/source/core/data/table2.cxx:1527: bTableAreaValid = false; > > So thought there could be 1 use of "bTableAreaVisibleValid" lacking. > Moreover, this var is new from this patch. > I can just tell I don't reproduce the pb with this patch. > Now we can also wait for Jenkins results and its check tests. yep, let's wait. Another option would be to revert it in 7.2/7.2.0 only and apply your patch to master only. it looks much safer that way
(In reply to Xisco Faulí from comment #10) > ... > > yep, let's wait. Another option would be to revert it in 7.2/7.2.0 only and > apply your patch to master only. it looks much safer that way About reverting, I can just say there'll be a conflict to solve on master or on libreoffice-7-2 branch.
(In reply to Julien Nabet from comment #11) > (In reply to Xisco Faulí from comment #10) > > ... > > > > yep, let's wait. Another option would be to revert it in 7.2/7.2.0 only and > > apply your patch to master only. it looks much safer that way > > About reverting, I can just say there'll be a conflict to solve on master or > on libreoffice-7-2 branch. Yep, they are already fixed in the latest patch of https://gerrit.libreoffice.org/c/core/+/120444
Julien Nabet committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/faee2796e3f3d98521b4b23b167b688171560254 tdf#143896: FILESAVE XLS(X) 1001+ rows are lost after saving new file It will be available in 7.3.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.
Thank you Xisco for the review. I saw the patch for 7.2 branch here:https://gerrit.libreoffice.org/c/core/+/120449 I didn't find the one for 7.2.0 branch, do you still want we cherry-pick it for this branch too?
(In reply to Julien Nabet from comment #14) > Thank you Xisco for the review. > I saw the patch for 7.2 branch > here:https://gerrit.libreoffice.org/c/core/+/120449 > > I didn't find the one for 7.2.0 branch, do you still want we cherry-pick it > for this branch too? yep, but make sure jenkins passes in 7.2 branch first
Julien Nabet committed a patch related to this issue. It has been pushed to "libreoffice-7-2": https://git.libreoffice.org/core/commit/ab6c339faa15bf324f1161678717f02dbf8c19f6 tdf#143896: FILESAVE XLS(X) 1001+ rows are lost after saving new file It will be available in 7.2.1. 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/ea7b9f87556414d37b83a5dd45cd944d97597ad1 tdf#143896: sc_uicalc: Add unittest It will be available in 7.3.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.
Xisco Fauli committed a patch related to this issue. It has been pushed to "libreoffice-7-2": https://git.libreoffice.org/core/commit/1a73d70ffc834ff4ff29e13b1d1c06be60ce58b5 tdf#143896: sc_uicalc: Add unittest It will be available in 7.2.1. 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.3.0.0.alpha0+ / LibreOffice Community Build ID: 615a340fcf05845397ea3c9917e2eadf074b4514 CPU threads: 4; OS: Linux 5.10; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded @Julien, thanks for fixing this issue so fast!!
Julien Nabet committed a patch related to this issue. It has been pushed to "libreoffice-7-2-0": https://git.libreoffice.org/core/commit/376d9889bcd61dbfc0531b2168e2f04736d81d49 tdf#143896: FILESAVE XLS(X) 1001+ rows are lost after saving new file It will be available in 7.2.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.