Bug 107153 - DISPLAY: row headers misaligned with data (wrap text, vertical: top)
Summary: DISPLAY: row headers misaligned with data (wrap text, vertical: top)
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
5.2.6.2 release
Hardware: x86-64 (AMD64) Linux (All)
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Calc-Cells
  Show dependency treegraph
 
Reported: 2017-04-13 22:58 UTC by Terrence Enger
Modified: 2025-05-12 03:10 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
screenshot of misaligned row headers (105.30 KB, image/png)
2017-04-13 23:01 UTC, Terrence Enger
Details
example spreadsheet (3.19 KB, text/csv)
2017-04-13 23:02 UTC, Terrence Enger
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Terrence Enger 2017-04-13 22:58:32 UTC
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
Comment 1 Terrence Enger 2017-04-13 23:01:17 UTC
Created attachment 132551 [details]
screenshot of misaligned row headers
Comment 2 Terrence Enger 2017-04-13 23:02:57 UTC
Created attachment 132552 [details]
example spreadsheet
Comment 3 Buovjaga 2017-04-16 17:20:19 UTC
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
Comment 4 QA Administrators 2018-04-17 02:31:00 UTC Comment hidden (obsolete)
Comment 5 Terrence Enger 2018-04-17 23:38:28 UTC
I still see the problem on debian-buster in daily Linux dbgutil
bibisect repository version 2018-04-17.
Comment 6 QA Administrators 2019-04-18 03:04:23 UTC Comment hidden (obsolete)
Comment 7 Terrence Enger 2019-04-19 18:12:25 UTC
On debian-buster, in bibisect-linux_64-6.3 commit 0eaa0804
(2019-04-15), I still see the bug.
Comment 8 QA Administrators 2021-04-19 03:39:18 UTC Comment hidden (obsolete)
Comment 9 Terrence Enger 2021-04-22 01:16:39 UTC
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.
Comment 10 Buovjaga 2021-04-22 05:56:23 UTC
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.
Comment 11 Terrence Enger 2021-06-19 16:12:21 UTC
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.
Comment 12 QA Administrators 2025-05-12 03:10:36 UTC
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://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug