Created attachment 142385 [details] test Problem description: When you delete a row or add a column it decreases the height of the rows in the spreadsheet Steps to reproduce: 1. Open the attached file. 2. Delete the second row. or 1. Open the attached file. 2. add a column between column B and C. Operating System: All Version: 6.1.0.0.alpha0+ Master
Apparently, this occurs when you have merged cells in the first column.
Hi Salim, I don't reproduce with LO 6.1.0.0.alpha1+ Build ID: 23c5125148a8110d88385b29570bf0b7d4400458 CPU threads: 2; OS: Windows 6.1; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2018-05-12_00:15:25 Locale: fr-FR (fr_FR); Calc: CL LO 5.4.0.1 Build ID: 962a9c4e2f56d1dbdd354b1becda28edd471f4f2 Threads CPU : 2; OS : Windows 6.1; UI Render : par défaut; Locale : fr-FR (fr_FR); Calc: CL Can you precise your OS, please?
Hi Jacques, I reproduce it on: LO Version: 6.1.0.0.alpha0+ Build ID: 24a57e2b854a1b8b3b8533ac72a6614ee29e374a CPU threads: 8; OS: Linux 4.4; UI render: default; VCL: gtk2; Locale: fr-FR (fr_FR.UTF-8); Calc: group and LO Version: 5.4.7.2 (x64) Build ID: 8b8bb024e6d958c001e1f2765f61077f5a6a3a30 CPU threads: 2; OS: Windows 6.19; UI render: default; Locale: en-US (en_US); Calc: grou
Created attachment 142407 [details] Screen before removing a row
Created attachment 142408 [details] Screen after removing a row
Thank you for this information completion. However, I still see no width modification. They are the same before and after the row deletting: 8.77 cm. Obviously, I see the red arrow apearing after the deletting. I thought to a side effect, but when I use undo(Ctrl+z) and redo(Ctrl+y), those red arrows desappear. Is this the problem you see here and do you correct it this way?
Look at the row number 14 after removing the second row. The text completely disappear.
i don't see a red arrow but (Ctrl+z) and redo(Ctrl+y) works.
I investigate this bug in my opinion the problem comes from this file. libreoffice\sc\source\ui\docshell\docfunc.cxx in line 2425. Calc uses a different deletion when you have merged cells in your spreadsheet.
Regression introduced by: author Markus Mohrhard <markus.mohrhard@googlemail.com> 2013-01-22 23:50:47 +0100 committer Markus Mohrhard <markus.mohrhard@googlemail.com> 2013-01-22 23:52:09 +0100 commit 62bf434229f9f86469dea3123bc6180bd9979c2c (patch) tree 4b64aae8b8f2e99a146e4afc931639638d3f3639 parent c4b3af1e9f069d7d922974565ee66a30fd5744e4 (diff) reset automatic row height flag after import, fdo#59193 Bisected with: bibisect-41max Adding Cc: to Markus Mohrhard Moving to ASSIGNED
Hello, I fixed the bug on version 5.4 of LibreOffice but the code is different on version 6. I am still looking for a solution for version 6.
Dear Salim Habchi, This bug has been in ASSIGNED status for more than 3 months without any activity. Resetting it to NEW. Please assigned it back to yourself if you're still working on this.
Dear Salim Habchi, 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 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: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Bug still existing in LibreOffice version Version 6.4.4.2.
(In reply to david.vantyghem from comment #14) > Bug still existing in LibreOffice version Version 6.4.4.2. Thanks for rechecking. The "Version" field is used for the earliest version affected though, so should stay unchanged.
Repro 7.2+. But row 14 is already small on fileopen. That seems more clear than Lo 4.1 where that row becomes wrong only after delete of row 2. I'm not convinced in regression, same problem with delete in 3.5.7, although it looks fine on fileopen. In OO 3.3 first row is smaller. Workaround is to Optimal height all or used rows. I decrease importance. It should be raised if repro steps from scratch can be found or similar bugs related via See Also.
Dear Salim Habchi, 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
The behavior as of: Version: 7.4.5.1 (x64) / LibreOffice Community Build ID: 9c0871452b3918c1019dde9bfac75448afc4b57f CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: default; VCL: win Locale: en-US (es_AR); UI: en-US Calc: CL ...is different than the original in comment 0 when comparing to the screenshot in comment 4, as Timur describes in comment 17, but there is still an issue. 1. Open attachment 142385 [details] from comment 0. 2. Click cell B1. 3. Menu Format > Rows > Height... 3.1. Note the value. [ESC] 4. Click cell B14. 5. Menu Format > Rows > Height... 5.1. Note the value. [ESC] 6. Right-click header row 14 > Row Height... 6.1. Note the value. [ESC] 7. Select cell B14:C14 (or _select_ at least one cell in row 14) 8. Right-click header row 14 > Row Height... 8.1. Note the value. [ESC] Value in 6.1 equals value in 3.1 > incorrect. Value in 6.1 differs value in 5.1 > incorrect. Value in 8.1 equals value in 5.1 > OK. This seems to be related to the merged cells in column A. When no cell is selected, right-click row header > Row Height... provides information of the first row of the merged cells of column A. I haven't tested whether this is always about column A, or it would happen also for freeze panes and/or split windows situations (i.e. when the "first" column is not necessarily column A). Side-note: unmerging and [ctrl]+[z] leaves a different height than what was initially set.