Bug 123282 - Any action in spreadsheet increases row height
Summary: Any action in spreadsheet increases row height
Status: RESOLVED INSUFFICIENTDATA
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
6.2.0.3 release
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Cell-Management
  Show dependency treegraph
 
Reported: 2019-02-09 10:01 UTC by Przemysław
Modified: 2020-02-11 03:30 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Spreadsheet before entering new column (54.99 KB, image/png)
2019-02-09 10:02 UTC, Przemysław
Details
Spreadsheet after new column was entered (13.41 KB, image/png)
2019-02-09 10:03 UTC, Przemysław
Details
Spreadsheet __after__ clicking __undo and redo__ (16.90 KB, image/png)
2019-02-09 10:04 UTC, Przemysław
Details
4th atachment, read comments (21.52 KB, image/png)
2019-02-09 17:04 UTC, Przemysław
Details
5th atachment, read comments, column's Title width (10.79 KB, image/png)
2019-02-09 17:05 UTC, Przemysław
Details
Test file for testing observed bad behavior (32.63 KB, application/vnd.oasis.opendocument.spreadsheet)
2019-02-09 20:52 UTC, Przemysław
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Przemysław 2019-02-09 10:01:36 UTC
Description:
Entering column or changing cell padding settings the defined row height is expanded. Then clicking undo and redo change spreadsheet to new settings and the former height.

Steps to Reproduce:
1. enter new column or
2. select a cell or cells, open "cell format" and change border padding
3. your cells' height is changed so press "undo" _then_ "redo" - your changes will be accepted and the heights will come back to former values

Actual Results:
New format settings are accepted.

Expected Results:
Do not coerce me to use trick __undo and redo__ click.


Reproducible: Always


User Profile Reset: No



Additional Info:
Comment 1 Przemysław 2019-02-09 10:02:48 UTC
Created attachment 149036 [details]
Spreadsheet before entering new column
Comment 2 Przemysław 2019-02-09 10:03:31 UTC
Created attachment 149037 [details]
Spreadsheet after new column was entered
Comment 3 Przemysław 2019-02-09 10:04:29 UTC
Created attachment 149038 [details]
Spreadsheet __after__ clicking __undo and redo__
Comment 4 Przemysław 2019-02-09 17:03:40 UTC
1) Probably it happens when one cell in a row is formated with wrapped text:
Format Cells -> Alignment -> Properties -> Wrap text automatically.

2) The rows without "typical" text cells were not touched by the height changes. What's more, it's enough when cells have text longer than content's of the column's title. See 4) screenshot (4th attachment)

3) So, it all suggests that Calc changes column width to default one based on column's title after _any_ e.g. copy process concerning any spreadsheet with text data. See 5) screenshot (5th attachment)

What a mess! :(
Comment 5 Przemysław 2019-02-09 17:04:25 UTC
Created attachment 149051 [details]
4th atachment, read comments
Comment 6 Przemysław 2019-02-09 17:05:04 UTC
Created attachment 149052 [details]
5th atachment, read comments, column's Title width
Comment 7 raal 2019-02-09 19:25:49 UTC
Hello,

Thank you for filing the bug. Please send us a sample document, as this makes it easier for us to verify the bug. 
I have set the bug's status to 'NEEDINFO', so please do change it back to 'UNCONFIRMED' once you have attached a document.
(Please note that the attachment will be public, remove any sensitive information before attaching it.)
How can I eliminate confidential data from a sample document?
https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F
Thank you
Comment 8 Przemysław 2019-02-09 20:52:10 UTC
Created attachment 149060 [details]
Test file for testing observed bad behavior

Please pay attention that one time data are correct in form time HH:MM, other as text e.g. '10:00. Probably the LO nasty behavior is result of my negligence to strict rules how to create correct Calc files.
Comment 9 Buovjaga 2019-07-14 15:39:45 UTC
Based on the screenshots, I went to column I, inserted column after, but there was no increase in row height.

Regarding border padding, I would expect the cell height to increase a bit (maybe it increased a lot in your case, but you did not provide numbers for before & after).

Do you still see this with 6.2.5 or 6.3?

Set to NEEDINFO.
Change back to UNCONFIRMED, if the problem persists. Change to RESOLVED WORKSFORME, if the problem went away.

Arch Linux 64-bit
Version: 6.2.5.2
Build ID: 6.2.5-1
CPU threads: 8; OS: Linux 5.2; UI render: default; VCL: kde5; 
Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US
Calc: threaded

Arch Linux 64-bit
Version: 6.4.0.0.alpha0+
Build ID: 1ce1c26dd98e6477139e08d1ebe89fa950ff5fb0
CPU threads: 8; OS: Linux 5.2; UI render: default; VCL: gtk3; 
Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US
Calc: threaded
Built on 12 July 2019
Comment 10 QA Administrators 2020-01-11 03:54:08 UTC Comment hidden (obsolete)
Comment 11 QA Administrators 2020-02-11 03:30:45 UTC
Dear Przemysław,

Please read this message in its entirety before proceeding.

Your bug report is being closed as INSUFFICIENTDATA due to inactivity and
a lack of information which is needed in order to accurately
reproduce and confirm the problem. We encourage you to retest
your bug against the latest release. If the issue is still
present in the latest stable release, we need the following
information (please ignore any that you've already provided):

a) Provide details of your system including your operating
   system and the latest version of LibreOffice that you have
   confirmed the bug to be present

b) Provide easy to reproduce steps – the simpler the better

c) Provide any test case(s) which will help us confirm the problem

d) Provide screenshots of the problem if you think it might help

e) Read all comments and provide any requested information

Once all of this is done, please set the bug back to UNCONFIRMED
and we will attempt to reproduce the issue. Please do not:

a) respond via email 

b) update the version field in the bug or any of the other details
   on the top section of our bug tracker

Warm Regards,
QA Team

MassPing-NeedInfo-FollowUp