Bug 148008 - autofit column width by cell selection using wrong width
Summary: autofit column width by cell selection using wrong width
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
4.2.0.4 release
Hardware: All All
: medium normal
Assignee: Mike Kaganski
URL:
Whiteboard: target:7.6.0 target:7.5.3
Keywords: bibisected, regression
Depends on:
Blocks:
 
Reported: 2022-03-15 14:42 UTC by Ryan Sarson
Modified: 2023-04-06 14:51 UTC (History)
0 users

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ryan Sarson 2022-03-15 14:42:54 UTC
Description:
autofit column width by cell selection uses width of widest cell below selected cell instead of width of selected cell

Steps to Reproduce:
1. in column a:
     123456789
        123456
           123
        654321
     987654321
2. select & highlight 123 (ie, click & hold the cell, drag down & back up a cell to ensure it is highlighted and not just selected)
3. double-click the right column border at the top (when the two way arrow is visible) to trigger autofitting the column width
4. do the same but delete the last 987654321 beforehand

Actual Results:
after 3., column width will be as wide as 123456789
after 4., column width will be as wide as 123456


Expected Results:
after 3. and 4., column width should be as wide as 123


Reproducible: Always


User Profile Reset: No


OpenGL enabled: Yes

Additional Info:
this feature has been buggy & finicky over several versions now.  it seems every other time there is an update, there is a different issue/result when trying to autofit columns.  sorry to not be more precise, i just wanted to highlight that i've been dealing with this for a while now and finally decided to file a bug report about it
Comment 1 Scott Clewell 2022-03-18 00:55:22 UTC
Hello Ryan,

Thank you for reporting the bug. I can confirm that the bug is present in

Version: 7.3.1.3 / LibreOffice Community
Build ID: 30(Build:3)
CPU threads: 16; OS: Linux 5.13; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Ubuntu package version: 1:7.3.1~rc3-0ubuntu0.20.04.1~lo1
Calc: threaded

and in

Version: 7.4.0.0.alpha0+ / LibreOffice Community
Build ID: cb56edb177f4db5b9cc4d140543c4b11d41ef1b0
CPU threads: 16; OS: Linux 5.13; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: CL
Comment 2 Mike Kaganski 2023-03-17 07:42:23 UTC
This is a regression. This worked in 4.1, and started to fail in 4.2, in the range https://git.libreoffice.org/core/+log/547f4fe%5E..6c5c0302.

Have these in A1, A2, and A3:

aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
bbbbb
ccccccccccccccccc

Let A4 be empty.

Double-clicking the border between A and B column headers:
Before:

* without selection -> A width resets to a default (does not fit any of the texts)
* A1 (or row 1) selected -> A width matches A1
* A2 (row 2) selected -> A width matches A2
* A3 (row 3) selected -> A width matches A3
* A4 (row 4) selected -> A width resets to a default (does not fit any of the texts)

After:

* without selection -> A width resets to a default (does not fit any of the texts)
* A1 (or row 1) selected -> A width matches A1
* A2 (row 2) selected -> A width matches A3
* A3 (row 3) selected -> A width matches A3
* A4 (row 4) selected -> A width resets to a default (does not fit any of the texts)

At some later point, there happened another change:

* without selection -> A width matches A1

The (later) change when no cell is selected looks reasonable; but the change of behavior (introduced in the said range) when row 2 is selected, so that all rows below are considered, look wrong.

Additionally, the changes in the range, that touch sc, are all targeted at automatic spell checking, so any change in cell width behavior looks accidental (if the bisection using linux-42max tells the truth).
Comment 3 Mike Kaganski 2023-03-17 09:32:34 UTC
https://gerrit.libreoffice.org/c/core/+/149026
Comment 4 ady 2023-03-17 09:50:29 UTC
FWIW (e.g. future tests for this), as of LO 7.4.5. the behavior depends on the location of the wider/widest content. The content of cells _below_ the selected one are taken into account, until there is a blank cell. The behavior is different when blank cells are present within the range of non-blank cells, or when the wider cell is on top.
Comment 5 ady 2023-03-17 10:10:42 UTC
Also, the behavior as of LO 7.4.5 is slightly different when the column has text vs having only numerical values.

Column A:
123
123456

123456789
123456789012

(third row blank empty)

Column B:
abc
abcdef

abcdefghi
abcdefghijkl

(third row blank empty)

1. Select A2 and adjust autowidth.
2. Select B2 and adjust autowidth.
3. Note diff.
Comment 6 Mike Kaganski 2023-03-17 10:29:18 UTC
(In reply to ady from comment #5)
> 3. Note diff.

I don't notice anything using 7.5.1; is this because I look in a wrong place, or because of a version? Ultimately, a comment talking about some phenomenon, but not describing it clearly (only using "Note diff" or the like) is not optimal ;)
Comment 7 ady 2023-03-17 10:48:47 UTC
(In reply to Mike Kaganski from comment #6)
> (In reply to ady from comment #5)
> > 3. Note diff.
> 
> I don't notice anything using 7.5.1; is this because I look in a wrong
> place, or because of a version? Ultimately, a comment talking about some
> phenomenon, but not describing it clearly (only using "Note diff" or the
> like) is not optimal ;)

To me the behavior seems slightly different, because the numbers didn't shrink to the point of ### (or spilled over to some adjacent column) but instead went to scientific notation, whereas the width of the text is not considered at all because there is a blank empty cell below the selected one. It might be just a combination of my font type, font size, zoom factor, the exact amount of digits, and who knows what else.

Comment 5 was intended as a continuation of comment 4, where I tested things like:

abc
abcdef
abcdefghi
abcdefghijkl

vs having some empty cells in between some of the rows, and
vs the inverted sorting order (with and without blank cells).

Depending on which cell I selected in each case for autowidth, the result was different, so at least it was clear that adjacent cells below were different than adjacent cells on top, and blank cells also influenced the behavior.

My original intention was to provide different sets of data and layout for testing the results. If none of these are taken into account in the code, then maybe I'm just seeing coincidences, depending on my own context.

Sorry for the noise.
Comment 8 Mike Kaganski 2023-03-17 10:58:15 UTC
(In reply to ady from comment #7)

1. The fact that only cells *below* affect the result is mentioned in comment 2.

2. You correctly noticed that blank cells stop the block outside of the selection where the width is considered. This is also true for other kinds of cell type change: e.g., have this in A1, A2, A3:

aaa
aaaaa
1234567890

Select A2, and auto-fit. The width of A3 will not be taken into account, because it lives inside a different internal block (the column consists of three blocks internally: a1:a2 is text, A3 is numeric, A4 and below are empty).

3. Comment 5, which (likely) considers cells A4:B5, is completely irrelevant, because the change of formatting of wide numbers happens after the column width has changed (which, as usual, doesn't take the numbers after the blank into account).
Comment 9 Mike Kaganski 2023-03-17 11:08:54 UTC
(In reply to Mike Kaganski from comment #8)
> 1. The fact that only cells *below* affect the result is mentioned in
> comment 2.

And in comment 0 ;)
Comment 10 Commit Notification 2023-03-17 18:39:48 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/32b2d00853d049bacb60cfb40e732602da048c89

tdf#148008: do not proceed after the marked range

It will be available in 7.6.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.
Comment 11 Commit Notification 2023-04-06 14:51:51 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "libreoffice-7-5":

https://git.libreoffice.org/core/commit/f4e670e2543411ee15f8e3a2fff9b740168e1677

tdf#148008: do not proceed after the marked range

It will be available in 7.5.3.

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.