Download it now!
Bug 87420 - In-cell editing field is always top-aligned
Summary: In-cell editing field is always top-aligned
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
(earliest affected)
Inherited From OOo
Hardware: All All
: low normal
Assignee: Not Assigned
: 106426 (view as bug list)
Depends on:
Blocks: Calc-UX Cell-Edit-Mode
  Show dependency treegraph
Reported: 2014-12-17 19:44 UTC by saha
Modified: 2019-11-20 03:51 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description saha 2014-12-17 19:44:35 UTC
Problem description: when typing into a cell the cursor automaticly go to top even if i have choosed an other vertical position

Steps to reproduce:
1. change vertical position other than TOP position
2. Type something

Current behavior: see problem description

Expected behavior: when typing into a cell the cursor should stay at the position that I choosed. It's not a real problem, but I think that it will give some fluidity when typing and maybe save some memory.

Sorry for my english

Best reguards
Comment 1 raal 2014-12-17 21:15:52 UTC
I can confirm with Version:
Build ID: e1de94244c1b0419c1c3415c02381e8b7a87abe0
TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:libreoffice-4-4, Time: 2014-12-14_11:45:23
Comment 2 QA Administrators 2015-12-20 16:06:49 UTC Comment hidden (obsolete)
Comment 3 saha 2015-12-20 19:30:13 UTC

This bug is still present with LibreOffice 
Build ID: 2b9802c1994aa0b7dc6079e128979269cf95bc78
Comment 4 QA Administrators 2017-01-03 19:46:23 UTC Comment hidden (obsolete)
Comment 5 Yousuf Philips (jay) (retired) 2017-10-04 17:03:26 UTC
still present

Build ID: 892c719fffa06de4c7aeab497326cad7bae9e5c6
CPU threads: 2; OS: Linux 4.4; UI render: default; VCL: gtk2; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2017-09-27_03:02:09
Locale: en-US (en_US.UTF-8); Calc: group
Comment 6 OfficeUser 2017-10-05 14:05:45 UTC
Thanks for the report. This is a very old but annoying issue.

Two things I want to note...

If you have something middle-aligned on a very high row (because neighbor cells contain much text) there is a enormous jump to the top of the string to be edited.

A               B                             A               B

                45646465                      middle-aligned  45646465
                56465465                                      56465465
                TestText                                      TestText
middle-aligned                     ==>> 
                45646465                                      45646465
                56465465                                      56465465
                TestText                                      TestText

[View mode]                                   [Edit mode]

There is functionality lost caused by this bug. In general it is possible to enter edit mode with a double-click exact on that position where you want to have the caret. With this bug the caret is always at the end of the cell content after a double-click.
Interesting: If you manage to double-click on the expected position at the cell top where the text will jump to, the caret will be at the intended position.
Comment 7 OfficeUser 2017-10-05 14:10:00 UTC
*** Bug 106426 has been marked as a duplicate of this bug. ***
Comment 8 OfficeUser 2017-11-18 21:51:32 UTC
Adjusted importance because of the extreme jumps described in my last comment.
Comment 9 QA Administrators 2018-11-19 03:39:47 UTC Comment hidden (obsolete)
Comment 10 OfficeUser 2018-11-19 13:21:26 UTC
Still reproducible with:
Comment 11 QA Administrators 2019-11-20 03:51:11 UTC
Dear saha,

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

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

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:

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

Warm Regards,
QA Team