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
cursor does not move up at 5. step
cursor ought to move up
User Profile Reset: No
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
Toggle Formatting Marks (CTRL+F10) and see what you delete exactly when you push Del. This key excluded, there is no moving issue.
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.
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
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 188.8.131.52 (Build ID: e183d5b)
Already repro in
Build ID: f3153a8b245191196a4b6b9abd1d0da16eead600
(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)
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
Adding Jürgen to CC.
To make the steps crystal clear:
1. Open attachment 136200 [details]
2. Down, down, down
(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 184.108.40.206
And here is another way to demonstrate with the same attachment, with cursor at the top.
1. Down, down, down
(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 ***