Bug 72203 - EDITING: in a table: moving upwards should go to the last line of the cell, not to the first
Summary: EDITING: in a table: moving upwards should go to the last line of the cell, n...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
4.1.3.2 release
Hardware: All All
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: ImpressDraw-Tables
  Show dependency treegraph
 
Reported: 2013-12-01 17:55 UTC by Jérôme Borme
Modified: 2024-02-03 03:15 UTC (History)
3 users (show)

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 Jérôme Borme 2013-12-01 17:55:42 UTC
Consider a table in Presentation/Impress that has cells with multiple lines.

When moving with the Down arrow in a cell, the cursor goes to the next line of the cell. Then, when in the last line of the cell, pressing one more time the Down arrow will move the cursor to the next cell. This is totally fine.

But now, you want to go back to the previous cell and press the Up arrow. What happens is that the cursor moves to the *first line* of the previous cell, while logic would imply you should go to the *last line* (the line right above the cell when pressing the Up arrow).

I put the severity to minor as there is no major functionality missing and workaround is obvious, but this is a daily annoyance when editing tables in Presentation that slows down the users' workflow.
Comment 1 sophie 2013-12-06 15:11:40 UTC
Hi Jérôme, I can't reproduce, with the Down arrow key, the cursor moves from A1 to A2 to A3, if this is the end of the column, then jump to B1, etc. If in B3 I hit the Up arrow key, it moves to B2 then B1, then A3. So works as expeted for me. 
Version Version: 4.1.3.2
Build ID: 70feb7d99726f064edab4605a8ab840c50ec57a Ubuntu 13.10
Comment 2 raal 2014-09-07 06:07:47 UTC
I can not confirm. Tested with version 4.2.6

Please, could you test with newer version? Setting bug as needinfo, set as unconfirmed again if problem still occurs in newer version. Thank you.
Comment 3 Jérôme Borme 2014-09-07 14:43:31 UTC
Actually my initial report was unclear. The issue is when the cells of the table have multiple-line text, for example a long sentence which gets spread over several lines (without pressing enter between lines).

Example:

/-----------\
|This is    |
|a sentence,|
|very long  |
|and all.   |
|-----------|
|Here is a  |
|different  |
|text, also |
|quite long.|
\-----------/

If the cursor is on |This, and you press the down arrow ↓, cursor will go to |a, |very, |and, |Here, |different, |text, |quite.

Now if you press the up arrow ↑, cursor will go to |text, |different, |Here, and then it will go to |This, skipping the other lines of the cell. I think cursor should instead go exactly in the opposite order as what it did before, which is going to |and, |very, |a, and only then to |This.

I tested just now with 4.2.5.2. I will test with 4.3 as soon as this version enters my distro (currently not compiling, see https://bugs.gentoo.org/show_bug.cgi?id=518664).
Comment 4 raal 2014-09-07 16:12:04 UTC
I can confirm with Version: 4.3.2.0.0+
Build ID: 5c1b508b172f0047d86e1acde92239ebf3438251
TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:libreoffice-4-3, Time: 2014-08-27_06:11:49

When go left in cells, then cursor jumps on last letter of the cell. When go up, then cursor jumps on first letter of the cell.
Comment 5 raal 2014-09-07 16:19:32 UTC
Notice the same behaviour with long multiple line text without Enter and multiple line text with Enter.
Comment 6 QA Administrators 2015-10-14 19:57:37 UTC Comment hidden (obsolete)
Comment 7 Buovjaga 2016-01-29 16:47:50 UTC
Repro comment 3

Win 7 Pro 64-bit Version: 5.2.0.0.alpha0+
Build ID: 259c1ed201f4277d74dfd600fed8c837cbf56abc
CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; 
TinderBox: Win-x86@39, Branch:master, Time: 2016-01-27_00:45:12
Locale: fi-FI (fi_FI)
Comment 8 QA Administrators 2017-03-06 14:02:21 UTC Comment hidden (obsolete)
Comment 9 QA Administrators 2020-02-02 03:40:03 UTC Comment hidden (obsolete)
Comment 10 Jérôme Borme 2020-02-02 14:17:20 UTC
Unchanged behaviour

Version: 6.3.4.2.0+
Build ID: Gentoo official package
Threads CPU : 32; OS : Linux 5.5; UI Render : par défaut; VCL: kde5; 
Locale : fr-FR (fr_FR.utf8); Langue IHM : fr-FR
Calc: threaded
Comment 11 QA Administrators 2022-02-02 03:40:29 UTC Comment hidden (obsolete)
Comment 12 Jérôme Borme 2022-02-02 13:01:01 UTC
Unchanged behaviour.

What I think is the correct behaviour is what LO Writer does.

In Writer, when one presses UP arrow while in the first line of a given table cell, it goes up one cell keeping cursor  visual position like if you would go up within paragraphs of a text. To me the behaviour of Writer is more natural than that of Impress.

("|" represents the cursor)

Writer:
/-----------\       /-----------\
|This is    |       |This is    |
|a sentence,|       |a sentence,|
|very long  | press |very long  |
|and  all.  |  UP   |and |all.  | "|all" 
|-----------|  -->  |-----------|
|Here|is a  |"Here|"|Here is a  |
|different  |       |different  |
|text, also |       |text, also |
|quite long.|       |quite long.|
\-----------/       \-----------/

Impress:
/-----------\       /-----------\
|This is    |       ||This is   | "|This"
|a sentence,|       |a sentence,|
|very long  | press |very long  |
|and  all.  |  UP   |and  all.  |
|-----------|  -->  |-----------|
|Here|is a  |"Here|"|Here is a  |
|different  |       |different  |
|text, also |       |text, also |
|quite long.|       |quite long.|
\-----------/       \-----------/


(In reply to QA Administrators from comment #11)

Version: 7.2.5.2.0+ / LibreOffice Community
Build ID: 20(Build:2)
CPU threads: 32; OS: Linux 5.16; UI render: default; VCL: kf5 (cairo+xcb)
Locale: pt-PT (fr_FR.utf8); UI: fr-FR
Gentoo official package
Calc: threaded
Comment 13 QA Administrators 2024-02-03 03:15:48 UTC
Dear Jérôme Borme,

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