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
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.
Cursor should've continued moving upwards following line ends
User Profile Reset: No
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.3
Created attachment 142551 [details]
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
repro in 6.1 beta 1 on Windows 10 64 bit both
Can you check this problem in previously versions of LibreOffice?
Build ID: c15927f20d4727c3b8de68497b6949e72f9e6e9e
Version 22.214.171.124.alpha0+ (Build ID: efca6f15609322f62a35619619a6d5fe5c9bd5a)
but not in
*** Bug 129983 has been marked as a duplicate of this bug. ***
Can confirm testcase still gives a problem with Versions 126.96.36.199 and 188.8.131.52.alpha.
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".
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.)
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]).
@Jürgen, this has been hanging around for some time  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?
(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)
adding "regression" based on Comment 5
Note that bug #119635 comment 2 says "no repro" Version: 184.108.40.206
while comment 5 here says "repro" for Version 220.127.116.11.alpha0+
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.)
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.
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).
Already in oldest of 43all Linux bibisect repo
*** Bug 133483 has been marked as a duplicate of this bug. ***
This looks like a duplicate of bug 124870
*** This bug has been marked as a duplicate of bug 124870 ***
(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.