Bug 118024 - cursor stops moving up under certain conditions
Summary: cursor stops moving up under certain conditions
Status: RESOLVED DUPLICATE of bug 124870
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
3.5.0 release
Hardware: All All
: medium normal
Assignee: Not Assigned
Keywords: preBibisect, regression
: 129983 133483 (view as bug list)
Depends on:
Blocks: Text-Cursor
  Show dependency treegraph
Reported: 2018-06-06 08:48 UTC by lvm
Modified: 2021-03-03 16:58 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:

testcase (14.60 KB, application/vnd.oasis.opendocument.text)
2018-06-06 08:49 UTC, lvm
simple test cases to demonstrate the cursor movement problem (11.12 KB, application/vnd.oasis.opendocument.text)
2020-01-13 15:48 UTC, sdc.blanco
shows variations of problem with same text fragment (14.50 KB, application/vnd.oasis.opendocument.text)
2020-02-03 09:18 UTC, sdc.blanco
Two similar cases with intriguing differences (16.86 KB, application/vnd.oasis.opendocument.text)
2020-02-03 17:17 UTC, sdc.blanco

Note You need to log in before you can comment on or make changes to this bug.
Description lvm 2018-06-06 08:48:30 UTC
when cursor positioned at the end of the line is moved up by keyboard up arrow it may jump to the start of the line and stop moving

Steps to Reproduce:
1. open the attached document
2. move cursor to the penultimate line of the last paragraph ('porttitor sodales neque, malesuada pellentesque erat luctus quis. Etiam eros augue, faucibus sit amet')
3. press End to move cursor to the end of line
4. start pressing Up repeatedly

Actual Results:  
Cursor moves up following line ends until it comes to the penultimate line of the first paragraph. Here instead of going one line up it goes to the beginning of the line and stops moving, subsequent Up keys are ignored.

Expected Results:
Cursor should've continued moving upwards following line ends

Reproducible: Always

User Profile Reset: No

Additional Info:

User-Agent: Mozilla/5.0 (X11; Linux i686; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.3
Comment 1 lvm 2018-06-06 08:49:11 UTC
Created attachment 142551 [details]
Comment 2 Xavier Van Wijmeersch 2018-06-06 16:32:14 UTC
following the steps in the discription
after step 4
The cursor jumps to the end of the first paragraph and moving the cursor up again it jumps to the start of the line bibendum arcu.... and stop moving 
Pressing the backspace and then space, its weird, but the cursor move's again to the top of the page

Build ID: 35c00b2ece11b7f60c5ffba10bd7083d4e7bc4f2
CPU threads: 8; OS: Linux 4.14; UI render: default; VCL: kde4; 
Locale: nl-BE (en_US.UTF-8); Calc: group threaded
Comment 3 Roman Kuznetsov 2018-06-06 18:22:25 UTC
repro in 6.1 beta 1 on Windows 10 64 bit both
Comment 4 Roman Kuznetsov 2018-06-06 18:23:33 UTC
Can you check this problem in previously versions of LibreOffice?
Comment 5 Xisco Faulí 2018-06-07 08:31:08 UTC
Reproduced in

Build ID: c15927f20d4727c3b8de68497b6949e72f9e6e9e

Version (Build ID: efca6f15609322f62a35619619a6d5fe5c9bd5a)

but not in

LibreOffice 3.3.0 
OOO330m19 (Build:6)
tag libreoffice-
Comment 6 sdc.blanco 2020-01-13 14:31:44 UTC
*** Bug 129983 has been marked as a duplicate of this bug. ***
Comment 7 sdc.blanco 2020-01-13 14:40:05 UTC
Can confirm testcase still gives a problem with Versions and

Would also like to recommend attachment 157121 [details] because (a) it gives simpler test cases to illustrate the problem, and (b) the first case illustrates a variation on the theme.  (Please ignore the "deleting" stuff in the attachment.  After reading this bug, I discovered the "stuck" problem can be experienced by simply moving the cursor upwards -- no deleting needed.)

Sorry for duplicate. Tried to find other bugs before submitting mine, but was focused on the command, not the "cursor".
Comment 8 sdc.blanco 2020-01-13 15:13:20 UTC
Please note that bug 112351 has another test case that shows the same kind of problem, but now starting by moving the cursor down and then cannot go up.

Also note that bug 112351 and bug 119635 have bibisects that identify the same commit as the source of the problem. 


Both bug 112351 and bug 119635 refer to deleting text as prior to the problem.  As did my duplicate bug 129983.  The "deleting" may be irrelevant (as already mentioned in comment 7 here for bug 129983) and in bug 112351, comment 12 I show how the "bug" can be produced without having to use delete.  Have not investigated bug 119635 in relation to this question.

(I think the "deleting" has appeared in the bug reports, because in practice we encounter the bug after deleting, but it is not relevant for producing the bug.)
Comment 9 sdc.blanco 2020-01-13 15:48:14 UTC
Created attachment 157127 [details]
simple test cases to demonstrate the cursor movement problem

Attached are two simple tests cases that show the two variations I have observed in the testcase here and in my testcase in attachment 157121 [details].

A critical element is that the cursor starts at the far right edge of the document canvas, but it does not have to be a paragraph (see the second variation in attachment 157121 [details]).
Comment 10 V Stuart Foote 2020-01-13 16:09:04 UTC
@Jürgen, this has been hanging around for some time [1] but as Seth points out there are a number of issues in normal cursor X and Y movement inside a paragraph that seem to hang up at cursor transition into the top line. Lose ability to reposition the cursor upward with cursor stuck on the second line.

His attachment 157127 [details] has a nice reporducing test document & STR

Do you have a little time to revisit this?



[1] https://gerrit.libreoffice.org/c/core/+/11500
Comment 11 Juergen Funk (CIB) 2020-01-14 06:21:20 UTC
(In reply to V Stuart Foote from comment #10)
> Do you have a little time to revisit this?

Hi V Stuart,

I don't have time right now, but maybe later I can get some time to look at it, but I'm not very familiar with it (the patch is 5 years ago)

Comment 12 sdc.blanco 2020-01-18 17:12:47 UTC
adding "regression" based on Comment 5

Note that bug #119635 comment 2 says "no repro"  Version:
while comment 5 here says "repro" for Version

Therefore bibisect for bug #112351 and bug #119635 (which identify the same commit) might not be the source of the problem for this bug report.  (however, bug #112351 reports a problem very similar to this bug #118024.)
Comment 13 sdc.blanco 2020-02-03 09:18:31 UTC
Created attachment 157610 [details]
shows variations of problem with same text fragment

This attachment (with simple instructions) uses the same text fragment to show variations in the problem.

Additionally, if some letters are substituted in the text fragment, then the problem can be eliminated.  As the bug summary says "under certain conditions".
Still do not know how to describe -- in general -- what conditions "trigger" the problem.
Comment 14 sdc.blanco 2020-02-03 17:17:37 UTC
Created attachment 157622 [details]
Two similar cases with intriguing differences

Have not been trying to find cases -- just encounter them.
Have updated the last attachment to include another case, very similar.
Still with slight differences about where the cursor stops and where it starts from, with no pattern (that I can discern).
Comment 15 Buovjaga 2020-06-08 14:50:03 UTC
Already in oldest of 43all Linux bibisect repo
Comment 16 Dieter 2020-09-22 20:12:55 UTC
*** Bug 133483 has been marked as a duplicate of this bug. ***
Comment 17 Xisco Faulí 2021-03-03 15:39:48 UTC
This looks like a duplicate of bug 124870

*** This bug has been marked as a duplicate of bug 124870 ***
Comment 18 lvm 2021-03-03 16:58:50 UTC
(In reply to Xisco Faulí from comment #17)
> This looks like a duplicate of bug 124870
> *** This bug has been marked as a duplicate of bug 124870 ***

Not sure about that at all - this bug has nothing to do with hyphens, my testcase has 0 hyphens in it. And if it is, this bug was reported earlier :) Actually I suspect it is caused by the line length, it always happens at longer lines.