Created attachment 142385 [details]
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.
1. Open the attached file.
2. add a column between column B and C.
Operating System: All
Version: 126.96.36.199.alpha0+ Master
Apparently, this occurs when you have merged cells in the first column.
I don't reproduce with
LO 188.8.131.52.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 184.108.40.206 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?
I reproduce it on:
LO Version: 220.127.116.11.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
LO Version: 18.104.22.168 (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 <firstname.lastname@example.org> 2013-01-22 23:50:47 +0100
committer Markus Mohrhard <email@example.com> 2013-01-22 23:52:09 +0100
commit 62bf434229f9f86469dea3123bc6180bd9979c2c (patch)
parent c4b3af1e9f069d7d922974565ee66a30fd5744e4 (diff)
reset automatic row height flag after import, fdo#59193
Bisected with: bibisect-41max
Adding Cc: to Markus Mohrhard
Moving to ASSIGNED
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!
Bug still existing in LibreOffice version Version 22.214.171.124.
(In reply to david.vantyghem from comment #14)
> Bug still existing in LibreOffice version Version 126.96.36.199.
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.