Bug 112351 - Cursor does not move up in long word after removing paragraph break
Summary: Cursor does not move up in long word after removing paragraph break
Status: RESOLVED DUPLICATE of bug 93441
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.4.7.2 release
Hardware: All All
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, regression
Depends on:
Blocks: Text-Cursor
  Show dependency treegraph
 
Reported: 2017-09-12 14:07 UTC by Antti
Modified: 2020-12-19 19:22 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
A file with which the bug can be repeated (16.97 KB, application/vnd.oasis.opendocument.text)
2017-09-12 14:09 UTC, Antti
Details
Modified place for cursor to illustrate the issue (16.09 KB, application/vnd.oasis.opendocument.text)
2017-09-13 00:09 UTC, Antti
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Antti 2017-09-12 14:07:42 UTC
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
Comment 1 Antti 2017-09-12 14:09:30 UTC
Created attachment 136200 [details]
A file with which the bug can be repeated
Comment 2 Jacques Guilleron 2017-09-12 20:37:31 UTC
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.
Comment 3 Antti 2017-09-13 00:07:52 UTC
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?
Comment 4 Antti 2017-09-13 00:09:17 UTC
Created attachment 136215 [details]
Modified place for cursor to illustrate the issue
Comment 5 Xisco Faulí 2017-09-13 09:41:54 UTC
You can't confirm your own bugs. Moving it back to UNCONFIRMED until someone else confirms it.
Comment 6 Jean-Baptiste Faure 2017-09-26 20:30:31 UTC
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
Comment 7 Antti 2017-09-26 20:53:07 UTC
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
Comment 8 Buovjaga 2017-11-01 16:23:22 UTC
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)
Comment 9 Buovjaga 2017-11-01 16:34:43 UTC
Already repro in
Version: 4.4.7.2
Build ID: f3153a8b245191196a4b6b9abd1d0da16eead600
Locale: fi_FI
Win 10
Comment 10 Antti 2017-11-01 16:51:05 UTC
(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.
Comment 11 Buovjaga 2018-05-25 18:34:20 UTC
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
Comment 12 sdc.blanco 2020-01-13 15:00:02 UTC
(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.
Comment 13 Telesto 2020-12-19 19:22:47 UTC

*** This bug has been marked as a duplicate of bug 93441 ***