Bug 119635 - Writer: incorrect cursor placement when moving to next paragraph after deleting text
Summary: Writer: incorrect cursor placement when moving to next paragraph after deleti...
Status: RESOLVED DUPLICATE of bug 93441
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.4 all versions
Hardware: All All
: low minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Text-Cursor
  Show dependency treegraph
 
Reported: 2018-09-01 17:57 UTC by Octavio Alvarez
Modified: 2020-12-19 19:22 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Bibisect log (3.62 KB, text/plain)
2018-09-05 20:12 UTC, Telesto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Octavio Alvarez 2018-09-01 17:57:05 UTC
Description:
It looks like Writer keeps track of the horizontal location of the cursor in pixels instead of character number. When erasing a word and this moves the cursor, it seems that Writer does not properly update this value. When moving to the next paragraph, the cursor ends up in the wrong location.

Steps to Reproduce:
1. New Writer document.
2. Type "Hello beautiful world". Hit Enter.
3. Type "Hello beautiful world" again. Hit Enter.
4. Select the word "beautiful" you can use either double-click the word or use Shift+Right to select the word from left to right.
5. Press "Delete".
6. Press the Down arrow.

Actual Results:
Moving to the next paragraph places the cursor at the end of "beautiful" in the second paragraph.

Expected Results:
Moving to the next paragraph should place the cursor at the beginning of "beautiful" in the second paragraph.


Reproducible: Always


User Profile Reset: No



Additional Info:
This does not happen if the word is selected from right to left. It is possible to see the cursor position while the word is selected, so it is clear to see that when selecting from right to left this problem does not occur because the cursor is at the beginning of "beautiful" before deleting the word.

This even occurs after writing some text!
1. Redo all the steps until step 5.
...
5. Press "Delete" (this step is optional, happens whether done or not)
6. Type "cruel". Do not press Enter.
7. Press the "Down arrow".

Same behavior. The cursor should be at the middle of "beautiful". Instead, Writer places the cursor at the end.



Version: 6.1.0.2
Build ID: 1:6.1.0~rc2-3
CPU threads: 4; OS: Linux 4.2; UI render: default; VCL: gtk3; 
Locale: en-US (en_US.utf8); Calc: group threaded
Comment 1 V Stuart Foote 2018-09-01 18:46:57 UTC
Confirmed on Windows 10 Home 64-bit en-US with
Version: 6.2.0.0.alpha0+
Build ID: 22f2d8c41aa0a0a4cfa215c07ec06ae38cde7da8
CPU threads: 4; OS: Windows 10.0; UI render: GL; 
TinderBox: Win-x86@42, Branch:master, Time: 2018-08-29_04:32:58
Locale: en-US (en_US); Calc: threaded

and with
Version: 5.3.7.2 (x64)
Build ID: 6b8ed514a9f8b44d37a1b96673cbbdd077e24059
CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; Layout Engine: new; 
Locale: en-US (en_US); Calc: group

It happens with both deletion, or insertion of characters, words, or white space within a multi-line paragraph, and between paragraphs as noted.

To be more obvious use the "DT" -> F3 autotext, and change font to a fixed width like Courier New.

Deleting or inserting glyphs on a line of text, and using cursor up or down to move to prior or next line, or to next paragraph.

Position of the cursor on in the new line will be the prior position--from before deletion or insertion.

Seems a little disjointed for efficient text editing.
Comment 2 Telesto 2018-09-02 08:07:33 UTC
No repro with
Version: 4.3.7.2
Build ID: 8a35821d8636a03b8bf4e15b48f59794652c68ba
Comment 3 Telesto 2018-09-05 20:12:23 UTC
Created attachment 144703 [details]
Bibisect log

Bisected to:

author	Juergen Funk <juergen.funk_ml@cib.de>	2014-09-17 16:31:20 +0200
committer	Samuel Mehrbrodt <s.mehrbrodt@gmail.com>	2014-09-22 08:01:57 +0000
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

https://cgit.freedesktop.org/libreoffice/core/commit/?id=d58bea0ffa2a2fe79103ab7aa743aea63e27a0fd
Comment 4 Telesto 2018-09-07 07:25:54 UTC
Adding CC: to Juergen Funk
Comment 5 Timur 2019-01-14 11:49:15 UTC
Repro 6.3+
Comment 6 Telesto 2020-12-19 19:22:21 UTC

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