Description: When I am trying to edit text, which I copied elsewhere with macro, the macro does not work because cursor does not move up on sertain cases. Steps to Reproduce: 1. Put cursor in specific place 2. press up 3. press end 4. press del 5. press up Actual Results: cursor does not move up at 5. step Expected Results: cursor ought to move up Reproducible: Always User Profile Reset: No Additional Info: I have included a file and put there a mark, where the cursor should be placed to reproduce the bug User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0
Created attachment 136200 [details] A file with which the bug can be repeated
Hi Antti, Toggle Formatting Marks (CTRL+F10) and see what you delete exactly when you push Del. This key excluded, there is no moving issue. Cordially.
In my opinion, software should be foreseeable and function always the same. In that light, it is not in my opinion tolerable that sometimes cursor goes up, and sometimes not. I illustrate it in the attachment I have included. Try to do the same rutine and put your cursor to the place I have marked in the attachment. You will see, that this time the cursor moves up when up arrow is pressed, as last step. How is it expleinable that some times cursor moves and other times does not? Should you have good explanation to this design philosophy, I would be glad to hear it. Otherwise it still remains as a flaw in my mind. I would also like to point out, that with cursor in this place, the whole line under, moves up, when del is pressed. At the first place only the formatting mark is removed, and the line above is not affected, or moved up. Instead, the cursor jumps one line down! I can not see, how this is not a bug... Could you explain it to me, please? Or is it some unseable marking issue?
Created attachment 136215 [details] Modified place for cursor to illustrate the issue
You can't confirm your own bugs. Moving it back to UNCONFIRMED until someone else confirms it.
There is no problem with normal text. Why did you remove spaces between words? Set status to NEEDINFO, please set it back to UNCONFIRMED once requested informations are provided. Best regards. JBF
I copied and pasted the text from a PDF-file in browser. For some reason, the spaces were removed automagically. Few of those removed spaces may also be due to my lousy macro. If it is the last one, the macro did exactly, what I described in my first comment. Hope that helped. - Antti
I reproduce the problem, even with a new file where I have paste the text as Unformatted. It is related to the long word that is longer than one line. The problem goes away after you click with the mouse to move the cursor. Then you can move as expected with the arrow keys. The interesting thing is that there is no problem in 3.6. So this is a regression. Arch Linux 64-bit, KDE Plasma 5 Version: 6.0.0.0.alpha1+ Build ID: af318eeb4e23694e17b09b902afb98ddf9da9b7b CPU threads: 8; OS: Linux 4.13; UI render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group Built on November 1st 2017 Arch Linux 64-bit Version 3.6.7.2 (Build ID: e183d5b)
Already repro in Version: 4.4.7.2 Build ID: f3153a8b245191196a4b6b9abd1d0da16eead600 Locale: fi_FI Win 10
(In reply to Buovjaga from comment #8) > > The problem goes away after you click with the mouse to move the cursor. > Then you can move as expected with the arrow keys. > Yes it goes, but the macro will (if I remember right) jam again, when another this kind of "long word that is longer than one line" comes ahead of it.
Bibisected on Windows to range https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=d58bea0ffa2a2fe79103ab7aa743aea63e27a0fd...3a7e54f5d2020ea1f6f2b27a51f5ca065844837f and https://cgit.freedesktop.org/libreoffice/core/commit/?id=d58bea0ffa2a2fe79103ab7aa743aea63e27a0fd seems the likely culprit. commit d58bea0ffa2a2fe79103ab7aa743aea63e27a0fd (patch) tree c297c1cb8e539dd0c5724039c8ee416cbbf1304d parent 6528a6ab7bee98503be763bcae7c57a4d0129ca1 (diff) Fix fdo#38884 Improve Up/Down movement in writer - It was provided, but the X-Position was reset after the cursor Up/Down - But in the Table is the X-Position not right -> other bug Change-Id: I2d70b7dc4ffa1e2612330d9b30ea5d916f5a9439 Reviewed-on: https://gerrit.libreoffice.org/11500 Adding Jürgen to CC. To make the steps crystal clear: 1. Open attachment 136200 [details] 2. Down, down, down 3. End 4. Del 5. Up
(In reply to Buovjaga from comment #11) > To make the steps crystal clear: > > 1. Open attachment 136200 [details] > 2. Down, down, down > 3. End > 4. Del > 5. Up Can confirm that this problem continues to appear in Version 6.4.3.2 And here is another way to demonstrate with the same attachment, with cursor at the top. 1. Down, down, down 2. End 3. Down 4. Up (no deleting needed!) I think this is a duplicate (or cousin) to bug 118024, while bug 119635 found the same commit in bibisect.
*** This bug has been marked as a duplicate of bug 93441 ***