Description: STR --- ( 1) Download the attached "three_columns_blank_isbn.csv". (Contrary to the filename, the column separator is <Tab>.) ( 2) Open that file. In the dialog "Text Import", accept the defaults. ( 3) Type "<Ctrl>+A". The program highlights all cells as selected. ( 4) Right-click over cell A1. ( 5) From the pop-up menu, select Format Cells... . Program presents dialog "Format Cells". ( 6) Click on tab Alignment. ( 7) Check Properties > "Wrap text automatically", and in drop-down list Vertical select Top. Type "<Enter>". Program returns focus to the main Calc window; all cells are still selected. ( 8) Select font "Liberation Mono". ( 9) Page down until row 36 is visible. Observe that cell A36 has contents "Row 36". (10) Drag the right edge of the header for column C to the left until the word "softcover" is truncated. The non-blank cells in column C show the red right-triangle signifying truncated cell contents. (This contradicts, for the moment, the "Wrap text..." option that we selected in step (7). Bug 57519 reports this problem.) (11) Click on the right edge of the header for column C. Most rows now are two lines high. Expected : The row headers at the left edge of the worksheet should be as high as the data rows, and they should be lined up with the data rows. Observed : The row headers at the left edge of the worksheet are each only one line high, and they are increasingly misaligned with the data rows as you look down the screen. (12) Type "<PageUp><PageDown>". The row headers are now corrected. (13) Drag the right edge of the header for column C to the right to accomodated the words in that column. Most rows remain two columns high. (Again, bug 57519 covers this.) (14) Type "<Tab>". The rows of data are now one line high. Expected : The row headers at the left edge of the worksheet should be one line high, and they should align with the rows in the data area. Observed : Most row headers are still two lines high, and they are increasingly misaligned with the data in the worksheet as you look down the screen. This long set of steps is shorter than it could have been. Along the way, I saw row headers repeated (something like 34, 35, 36, 37, 38, 36, 37, ...), with two row headers reverse-image to indicate current row. I see this behavior on debian stretch with both the delivered LibreOffice (Version: 5.2.6.2, Build ID: 1:5.2.6-2) and daily Linux dbgutil bibisect repository version 2017-04-13 (source hash b9573789). I am leaving default bug priority. But maybe it should be lower because the display problem is likely too gross to be more than momentarily confusing, and the workaround in step (9) is simple. Actual Results: Stated inline in STR. Expected Results: Stated inline in STR. Reproducible: Always User Profile Reset: No Additional Info: User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
Created attachment 132551 [details] screenshot of misaligned row headers
Created attachment 132552 [details] example spreadsheet
Repro. Tested also with 3.6, but step 11 does not do anything. Arch Linux 64-bit, KDE Plasma 5 Version: 5.4.0.0.alpha0+ Build ID: 9f5a275a42659339ee41c4e0a4d860f2886470e4 CPU threads: 8; OS: Linux 4.10; UI render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group Built on April 15th 2016
** Please read this message in its entirety before responding ** 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
I still see the problem on debian-buster in daily Linux dbgutil bibisect repository version 2018-04-17.
On debian-buster, in bibisect-linux_64-6.3 commit 0eaa0804 (2019-04-15), I still see the bug.
Dear Terrence Enger, 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://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
In a local build of commit 626da2da (2021-04-19), built and running on debian-buster, with SAL_USE_VCLPLUGIN=gen and xfce desktop, I still see the problem. I believe that the restriction to SAL=gen is new since I wrote comment 5.
I am noticing flaky behaviour with step 11, "Click on the right edge of the header for column C. Most rows now are two lines high." Most of the time it is not working. Unfortunately this can't be bibisected because the problem does not appear reliably.
In a local build of commit d95e400b (2021-06-18), built and running on debian-buster, with SAL_USE_VCLPLUGIN=gen and xfce desktop, I still see the problem. (Help > About shows "VCL:x11".) I believe but have not verified that the restriction to SAL=gen is new since I wrote comment 5.