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
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
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).
https://gerrit.libreoffice.org/c/core/+/149026
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.
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.
(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 ;)
(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.
(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).
(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 ;)
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.
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.