Description: 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
Created attachment 142551 [details] testcase
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 Version: 6.2.0.0.alpha0+ 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?
Reproduced in Version: 4.3.0.0.alpha1+ Build ID: c15927f20d4727c3b8de68497b6949e72f9e6e9e Version 4.1.0.0.alpha0+ (Build ID: efca6f15609322f62a35619619a6d5fe5c9bd5a) but not in LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4
*** Bug 129983 has been marked as a duplicate of this bug. ***
Can confirm testcase still gives a problem with Versions 6.3.4.2 and 6.5.0.0.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. https://cgit.freedesktop.org/libreoffice/core/commit/?id=d58bea0ffa2a2fe79103ab7aa743aea63e27a0fd 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 [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? Stuart =-ref-= [1] https://gerrit.libreoffice.org/c/core/+/11500
(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) Juergen
adding "regression" based on Comment 5 Note that bug #119635 comment 2 says "no repro" Version: 4.3.7.2 while comment 5 here says "repro" for Version 4.1.0.0.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.